gbracha / nullawareoperators Goto Github PK

a ?: b

looks more descriptive to me than

a ?? b

to me, because it contains both characters of the more verbose syntax

a ? a : b;

Question for @gbracha and @stereotype441

The proposal says that the semantics of a ??= b are the same as:

  a = a ?? b

This means, a will be assigned it's own value when it's not null. This can be observable if you do:

get v => 1
set v(value) { print('setter was called with $value');
main() {
  v ??= 2; // prints "setter was called with 1"
  v ??= 3; // prints "setter was called with 1"
}

However, some tests are written with a different semantics that avoids the assignment if the value is not null. In other words:

  ((v) => v == null ? a = b : v)(a)

I currently have the former implemented in dart2js and I'm inclined to change those tests to match, but I wanted to verify this was the intended behavior.

Currently named parameters with default values often become useless as explicitly passing null stops the default occurring.

For example

foo({String blah: 'blah'});

bar({String blah}) => foo(blah: blah);

If blah is null into bar then it will pass that to foo and the default value not used

So in practice you end up needing to do

foo({String blah}) {
  if (blah == null)  blah = 'blah'
}

This seems to happen so often as to almost render defaults on named parameters fairly useless.

Does this proposal provide any help for this case?

Does it need extra sugar? Dare I suggest

foo(blah ?: possiblyNullValue);

where the semantics are if possiblyNullValue is null then don't set the named parameter blah to method foo (leave it to default)

For example:

maybeList()?..addAll(list)

Operators are just a different kind of/syntax for method, so they should also be supported:
That is, let:

x ?+ 42

to be equivalent (in being supported) to

x ?.add(42)

Only works for binary operators.

The parsing might be problematic, since x ?-42 : 43 needs lookahead to the : to see that it's a conditional operator, not a null-aware minus. Maybe write it as "x?.+ y" instead, requiring the ?. sequence.

What should we expect with the ?. operator when used with assignments:

exp1?.x = exp2

My current expectation is that this should be equivalent to:

((a, b) => a == null ? null : a.x = b) (exp1, exp2);

(both expressions are evaluated once, exp2 is evaluated even when exp1 is null)

The current semantics of exp?.x are described in terms of evaluating this:

((a) => a == null ? null : a.x)(exp)

Because static fields cannot be read as instance members, this implies that we cannot use ?. with statics. Similarly, because we don't have first class libraries, we cannot use ?. with prefixes either.

This seems to match what the 07 test in conditional_property_access_test.dart checks, but I wanted to confirm before I implement this in dart2js.

This surprised me a little bit though. I was expecting that C?.x would be valid, it would issue a warning (e.g. "null-aware operators are not useful with statics"), but would otherwise execute as if the user had written C.x.

@gbracha @stereotype441 - what are your thoughts on switching to the latter?

I think instead of several ad-hoc cases (which don't cover all wishes anyway), we can use just a single one: (a??b)
Make ?? low precedence operator.
My claim is that all proposed constructs can be expressed much cleaner via (a??b)
E.g.
(x??y).foo=1;
(x??y)[42]=5
(x??y)=42 // for this, you can allow it to be lvalue, but syntactically it's the same)
z=(x??y)+42;

Note that we can use ?? like this even according to current proposal anyway. Which, together with other methods, leads to the same thing being expressible in different ways. (In another thread, Gilad said he wants to avoid such thing)

zip = lottery**.?drawWinner().?**address?.zipcode

All other compound assignment operators simply add = to the operator:

a += b ==> a = a + b
a >>= b ==> a = a >> b

It would be more consistent and obvious if ?= were instead ??=:

a ??= b ==> a = a ?? b