Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
jodinathan opened this issue Jul 6, 2022 · 10 comments
Open

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

jodinathan opened this issue Jul 6, 2022 · 10 comments
Labels
request Requests to resolve a particular developer problem

Comments

@jodinathan
Copy link

jodinathan commented Jul 6, 2022

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

@jodinathan jodinathan added the feature Proposed language feature that solves one or more problems label Jul 6, 2022
@julemand101
Copy link

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 jodinathan changed the title Alias for if null and if not null Are we thinking about an alias for if null and if not null? Jul 6, 2022
@jodinathan
Copy link
Author

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

@lrhn lrhn added request Requests to resolve a particular developer problem and removed feature Proposed language feature that solves one or more problems labels Jul 6, 2022
@mateusfccp
Copy link
Contributor

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
Copy link

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
Copy link
Author

// 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
Copy link

cedvdb commented Jul 8, 2022

There is the option of making null falsy and others truthy

@Levi-Lesches
Copy link

Levi-Lesches commented Jul 8, 2022

// 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
Copy link
Author

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
Copy link
Member

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.

@FMorschel
Copy link

FMorschel commented Dec 4, 2024

I'd prefer to add some extensions to the language core:

extension NullableVar on Object? {
  bool get isNull => this == null;
  bool get isNotNull => this != null;
}

extension NullableString on String? {
  bool get isNullOrEmpty => this == null || this.isEmpty;
  bool get isNotNullOrEmpty => this != null && this.isNotEmpty;
}

extension NullableIterable on Iterable? {
  bool get isNullOrEmpty => this == null || this.isEmpty;
  bool get isNotNullOrEmpty => this != null && this.isNotEmpty;
}

extension NullableMap on Map? {
  bool get isNullOrEmpty => this == null || this.isEmpty;
  bool get isNotNullOrEmpty => this != null && this.isNotEmpty;
}

I'm not sure it would solve the "shorthand" part but it would feel more Darty to have these getters IMO.


Edit

Related (or dupe) of #190

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
request Requests to resolve a particular developer problem
Projects
None yet
Development

No branches or pull requests

8 participants