Nullifying Conditional Operator

[Tech-Tac]

This proposal introduces a new syntax feature, the Nullifying Conditional Operator, which can be considered a shorthand for conditional ternary expressions where the else branch is always null.

Syntax

(please note that the specific syntax of the operator is still being discussed, see the syntax candidates section, ? will be used as a placeholder in the following examples)

Written in the form a ? b where:

• a is a Boolean expression.
• b is returned if a is true.
• Otherwise, if a is false, null is returned.

Example usage:

final bool hasDrawer = getHasDrawer();

return Scaffold(
  drawer: hasDrawer ? drawerWidget,
  // equivalent to drawer: hasDrawer ? drawerWidget : null,
  ...

Where in this example Scaffold would have a non-null drawer parameter if the boolean flag hasDrawer evaluates to true, or null otherwise.

Syntax candidates

• ?:: found too confusing by many
• ?&
• ?!
• ?

Use Cases

• Avoids repetitive null returns in ternary expressions
• Makes conditional expressions more concise
• Keeps code readable without introducing unnecessary verbosity
• Propagating a value based on a Boolean flag

---

Would love feedback from the community and the Dart team on feasibility and potential implementation!

[dart-github-bot]

Summary: User proposes a nullifying conditional operator (a ?: b), a shorthand for ternary expressions where the else is always null, improving conciseness.

[lrhn]

Seems arbitrary that it's the true branch that defaults to null, other than because it makes the operator name ?: work.
It would mean you can abbreviate x == null ? null : foo(x), but not x != null ? foo(x) : null, which is how I'd otherwise write it.

Even more, it becomes confusing: x == null ?: foo(x) reads more like calling foo if x is null.

I'd suggest introducing an if-expression instead: if (x != null) foo(x) as an expression (like it's already a collection element) could default to null if there is no else branch. Then you'd be omitting the else null at the end.

[Tech-Tac]

@lrhn My proposal is that the false/else branch is what default to null, if one wants it the other way around, they would reverse the condition.

[Tech-Tac]

An inline if expression (rather than a statement) would be welcome too, they both solve the same problem after all.

If the ?: syntax sounds too confusing, I thought of maybe using ?= instead, but it sounds too much like an assignment operator.

Or even perhaps make it :? instead?

If we had truthy values, we could write x && y.
But truthiness is out of fashion, so we need an extra symbol:
x &&& y.
Ugly?

[Tech-Tac]

Ugly?

Yeah, to some extent.

How about x ?& y
?
(There must be & somewhere, otherwise it will be confusing)

[Tech-Tac]

Yes, this looks better and makes some sense, can be a candidate.

[lrhn]

My proposal is that the false/else branch is what default to null

So it is. I stand by the syntax being confusing, because it looks like two opposite things at the same time.
If you know about test ? expr1 : expr2 and see test ?: expr, would you expect it to mean test ? null : expr (omitting the null) or test ? expr : null (putting the expr before the :). I would expect the former.

If you see foo == null ?: test(something) vs foo != null ?: test(something), which one runs test if foo is null?
(The former, probably.)

Too confusing for a syntax. Looking too much like ?/: while not working like it.

[Tech-Tac]

Ah, I misunderstood you earlier, sorry. You have a point, I didn't think about it like this (collapsed conditional ternary) but more of a standalone operator, but your interpretation makes more sense.

We may ultimately choose another syntax as ?: deemed confusing, what about ?& as suggested earlier or :? if we want to stick to the colon?

[lrhn]

Neither say "this if not null" to me.

An operator like this has been suggested a few times before.
It's like the dual of ?? for when the first value is not null. I can see why ?& would feel like && with an extra != null. I just don't like it, it looks like random line noise.
Maybe ?! to include the "null aware" and the "not null" parts.

It's really ?. with a non-member access afterwards. If we had implicit binding blocks, so you could write expr.{code} where the value of expr is bound to, fx, this or it inside the code block, then you can just do expr?.{foo(it)}.

[Tech-Tac]

I've got an idea, if this operator is supposed to equate to a conditional ternary with the else branch being null, let it be just that, just omit the : and the else value.

So instead of condition ? value : null it's just going to be condition ? value.

Am I onto something here?

[tenhobi]

But that might be hard to distinguish from ?., especially when stuff like Enum name can be omitted in the future.

final myValue = condition ? MyEnum.alpha : null;

to

final myValue = condition ? MyEnum.alpha;

to

final MyEnum myValue = condition ? .alpha; // see the issue here?