Please also support operators

[lrhn]

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.

[tatumizer]

There's a bit of inconsistency vs cascade operator. Cascade apparently allows []: cascadeSelector: ‘[’ expression ‘]’ | identifier

In the above proposal, array access via [] is not supported. So in the context of cascade [] gets first-class treatment (for some reason), but in nullAware it's just like everybody else. Example:

null?myMap.hashCode..[42] 

seems to be valid if we insert stupid hashCode, but without hashCode it won't work. Maybe nit-picking, but still....

[tatumizer]

Please see issue https://github.com/gbracha/nullAwareOperators/issues/5

[gbracha]

The proposal is by choice very simple. It's not like it actually adds any expressive power, so the trade off is between simplicity and sugar levels. It's obvious that this will bring in demand for more sugar, as noted in the proposal.

[munificent]

I get the consistency argument, but my feeling is that if you're using some expressions that are both nullable and using arithmetic operators, you've likely already lost the readability battle. Users almost always expect types that support arithmetic to be value types and, in turn, don't tend to expect variables using them to be nullable.

My opinion is :-1: