Null handling deficiencies

[JohnGalt1717]

Right now the dart analyser when faced with this:

final String? someValue;
...

String newValue = someValue == null ? 'test' : someValue;

Will error with nullability because it will tell you that you need to assert that someValue is not null right before the ;. It's obviously not null and any trinary operator case like this should automatically be handled and known.

Second case:

Consider the following function definition:

final bool Function()? someFunction;

In every other language with null safety that I could find I can execute it conditionally like this:

someFunction?() ?? someothervalue;

Dart doesn't allow that, but does allow it if the parent is null with the ?. operator. It should allow the ?() syntax as this gets rid of a TON of cases of having to use the trinary operator.

Third Case:

asert(someObject != null);

CallSomething(someObject.someProperty);

Because of the assert someObject is known from this point forward to be not null and shouldn't require the ! assertion.

Fourth:

There are numerous cases of If statements where a property must not be null as a result but in the body of the IF it won't know that it can't be null and require ! when it's not possible and you've already handled it.

Please consider correcting all of these cases so that we can stop using ! when it really isn't needed. Thanks!

[JohnGalt1717]

Ok on 1, and 4,
2, ok... that's kinda gross and very not discoverable....
3, ok, what's the suggested way of making the assertion other than when you first hit it? (this happens with GetIt and factoryParams that have to be nullable because of no reflection.)

[natebosch]

For more discussion on 1 and 4 see https://dart.dev/null-safety/understanding-null-safety#working-with-nullable-fields

2 - I'm not sure if we have an existing issue requestiong nullableFunction?() syntax. @leafpetersen are you aware of one? Should we file a new one?

3 - Assertions won't impact flow analysis because they might not happen, and since the null safety is sound it can't be used for flow analysis if it won't necessarily run. You can either use someObject!; as mentioned, or if (someObject == null) throw StateError('someObject should not be null here');

[Cat-sushi]

cf. #376

• There is concern about generalizing this. Specifically:
  • We will almost certainly want to add a null aware call operator. Whatever we choose for null aware subscript, we will almost certainly want null aware call to be the same. That implies that we either have a?[b] and f?(x, y) and f?<T, S>(x, y) or we have a?.[b] and f?.(x, y) and f?.<T, S>(x, y). We would almost certainly have to resort to the same tokenization hack to avoid ambiguities here as well (e.g. {f?(x):y}).

[leafpetersen]

2 - I'm not sure if we have an existing issue requestiong nullableFunction?() syntax. @leafpetersen are you aware of one? Should we file a new one?

This is tracked here.

[natebosch]

Closing since I think there isn't anything left to track here. Please follow and 👍 #404 and consider browsing the various proposals at field-promotion Issues related to addressing the lack of field promotion to see if there are any you'd like to 👍 as a solution for making the lack of field promotion more ergononomic.