Are we thinking about an alias for if null and if not null?

[jodinathan]

Sorry if already posted, I just couldn't find anything related.

What about a shorthand to if (foo == null) and if (foo != null)?

Maybe some simple stuff like

if (foo?) // same as foo == null

if (foo!) // same as foo != null

[julemand101]

Personally, I don't like this change, since it makes it less clear when null-checking are happening compared to the amount of characters actually being saved. There are also several cases with existing syntax where I think this could add confusion like e.g. ternary expressions: if (var? ? something() : somethingElse()).

Also, ! are already a thing so what does it even mean to say: if (var!) if var are a bool?? Does it check for null? Does it force a null-check and extract the value of the bool?

[jodinathan]

Yeah, my original post was to find an alternative to if null and if not null. The example just to foment the idea. Edited the post and title.

Currently checking for null is too verbose to something that happens a lot

[mateusfccp]

I don't think this is valuable at all... It's not like we make null checks all the time, nor like it's a verbose expression, so...

[Levi-Lesches]

I agree, I think "verbose" isn't the right way to describe it. A null check says exactly what it's doing, using syntax we're already familiar with, with no extra words:

if (value == null)

Read: "If value is/equals null". With a shorter syntax, we'd have to "unwrap" it in our heads as we read it.

[jodinathan]

// this
foo = foo == null ? bar : foo;

// became this
foo ??= bar;

I am assuming that the reasoning for the shorthand is because the prior is verbose to type and read.

IMO I find (value == null) verbose and semantically "incorrect".

For example, if we had something like:

if (?foo) // meaning foo is null

if (?!foo) // meaning foo is not null

We would be validating the nullability independently of the null keyword, this means we could have undefined and other kind of nullability keywords.
This was just a brainstorm example, not that we need an undefined kind of variable etc.

[cedvdb]

There is the option of making null falsy and others truthy

[Levi-Lesches]

// this
foo = foo == null ? bar : foo;

// became this
foo ??= bar;

This example is verbose because it says the word foo three times. Not to mention the ?: syntax is hardly intuitive and readable in the first place. IMO, if you really don't like syntax sugar, replace it with the full thing, it's even shorter and more readable.

if (foo == null) foo = bar;

IMO I find (value == null) verbose and semantically "incorrect".

...why? Again, it's not verbose, it's literally the minimum amount of characters/information needed to express "check if value is equal to null". Making it shorter isn't going to be cutting down on redundancy, it'll be adding special tokens you need to memorize to know it means the same thing. In any case, checking if value == null is definitely not semantically incorrect if you're actually checking that the value is null.

We would be validating the nullability independently of the null keyword

Again, how does this make it more "valid" or "correct"? An object's "nullability" just means whether it is or can be equal to null. Avoiding the word null isn't more correct at all, since it's directly tied to the notion of nullability.

[jodinathan]

using foo == null gives me a feeling that I am checking the equality of a hardcode constant ie bool isOdd(int n) => n == 1 || n == 3 instead of a someInt.isOdd or n % 2 == 0 etc.

As if the null keyword ever changes, it would break stuff.

So adding a shorthand to nullability also opens room for other possibilities.

[munificent]

Maybe some simple stuff like

if (foo?) // same as foo == null

if (foo!) // same as foo != null

Given how heavily overloaded ? and ! are already—nullable types, null-aware method call, conditional operator, null-aware spread, logical not—I think that would just cause more confusion than clarity. == null and != null are already fairly short completely clear in their meaning, so I think it's unlikely we'd come up with something better.