Proposal: operator !! (opposite of ??)

[MichaelRFairhurst]

Proposed solution to #360.

Where a ?? b is sugar for a != null ? a : b, there may be value in adding !! defined as a == null ? null : b.

Example: calling a function when the parameter is not null.

String? toPrint;
toPrint !! print(toPrint);

Example: awaiting a future when its not null

Future? fut;
fut !! await fut;

Example: asserting an object is fully initialized

assert(name !! age !! email !! password != null)

Similar to #219 except I think it has a few different advantages:

• extremely simple and consistent with an existing well-used and understood dart concept
• binary operator so left-to-right flow is easier to follow
• wouldn't interact with any other syntax (prefix ? is was proposed to interact with maps, lists, optional parameters, etc.)

Disadvantages:

• using ! and not throwing an exception on null is confusing. Maybe ?! or !??
• Limited usefulness
• repeat lhs required to take advantage of promotion

[lrhn]

With this definition, x! would be x ?? throw, and x?.foo() would be x !! x.foo().
Arguably, we have swapped the operators when we defined ?? (but then, we didn't have the suffix ! back then).

The operation, by itself, seems reasonable.
It may not be intuitive what x !! y means, and the places where it will be used, I don't think it looks very good.
The static typing works. If e1 has static type T1 and e2 has static type T2, then e1 !! e2 has static type T2?. That is a little confusing because it shows that the value of e1 is ignored except for the null-check.
That is also the biggest issue: you have to repeat the expression, which means you only get promotion for local variables. You can't do this.foo !! requiresNotNull(this.foo) because it won't promote. We should be able to promote var x = ...; x !! requiresNotnull(x);.

If you could write the !! on the expression, and that makes it break out of the context, then you only need to write it once: (? requiresNotNull(this.foo!!)) could evalute this.foo, then if it is null it shortcircuits the current expression and makes the surrounding (?...) evaluate to null.

[MichaelRFairhurst]

That is also the biggest issue: you have to repeat the expression, which means you only get promotion for local variables. You can't do this.foo !! requiresNotNull(this.foo) because it won't promote.

Great catch Lasse...

[mathieudevos]

As per #706 I would like to suggest a slight change: instead of !!; I would suggest the following: !?

[nex3]

As another data point, this has been a substantial source of pain in Dart Sass's null-safe refactor (I count about 40 instances of foo == null ? null : ...). For now, I'm using this (based on Rust's Option type):

extension NullableExtension<T> on T? {
  V? andThen<V>(V Function(T value) fn) {
    var self = this; // dart-lang/language#1520
    return self == null ? null : fn(self);
  }
}

but it's awkward, particularly due to the lack of constructor tear-offs.

That is also the biggest issue: you have to repeat the expression, which means you only get promotion for local variables. You can't do this.foo !! requiresNotNull(this.foo) because it won't promote.

Great catch Lasse...

#1201 provides a neat solution to this in (var this.foo) ?! requiresNotNull(foo).

[caseycrogers]

+1 to this proposal-regardless of the specific characters used to implement the operator.

I'm coming from Scala world where Options are king and the following is an extremely common paradigm:

Option<Foo> maybeFoo = getFoo();
bar(maybeFoo.map((val) => processFoo(val)));

This comes up commonly with default parameters in Dart:

int foo(String? overrideStr) => return (overrideStr != null ? int.parse(overrideStr) : null) ?? 42;
print(foo(maybeGetUserInput());

This is already supported if we're trying to call a class method. Notice how much readability improves when such an operator is supported:

extension StringToInt on String {
  int toInt() => int.parse(this);
}

int foo(String? overrideStr) => return overrideStr?.toInt() ?? 42;
print(foo(maybeGetUserInput());

Adding a "compute iff not null" operator would be highly useful and make writing functional-style code in Dart much friendlier.

[lrhn]

That map looks like an operation which Dart could just define:

extension OptionMap<T> on T? {
  R? map<R>(R? Function(T) convert) => this == null ? null : convert(this);
}

I'd have made it an operator if we could have generic operators.

[ykmnkmi]

Is dart supports operator type args?

[munificent]

Is dart supports operator type args?

No, operators cannot be generic methods in Dart.