Deprecate conditional operator ?/:

[Cat-sushi]

Motivation

NNBD, which is introducing many notations with ?, makes the ternary operator ?/: an eyesore more and more. For example, when null aware subscribing operation has shape of a?[b], then {a?[b]:c} is ambiguous at least mentally. The same thing goes for invocation {a?(b):c}.
In addition some proposals such as #357 might make the situation worse and worse.
T?, ??, ...?, and so on are OK, but ...

Note

This issue is derived from #376 and #729.
This issue aims to alternate the ternaly operation a ? b : c.
This issue doesn't treat collection-if or if-statement, directly.

Candidates of syntax

if(a) b else c // 1
if(a, b, c) // 2
if(a : b : c) // 3
and more

[lhk]

I'm very much in favour of doing something about the ternary operator.

Now, before NNBD syntax becomes sprinkled all over existing codebases, seems like an ideal time to let dartfmt do the heavy lifting of a syntax change. The ternary operator is still unique in its syntax and I think it should be possible to come up with a reasonably clean replacement.

That being said, using something based on if brings in lots of potential clashes with if statements, expressions and collection ifs. I think this is another corner of the language spec that is now proving to be kind of a dead end. It would be awesome to get if expressions. But collection-ifs will cause ambiguitiy. :(

[lrhn]

I'm not sure the ambiguity is that much of a problem for collection-ifs.
It may make parsing harder because you have to parse-ahead for a while before being able to distinguish the expression from the collection element, but in case of a full-on ambiguity, where the same text can be either, it likely also doesn't matter which one it is.
Because a list/set collection element can be an expression, it wouldn't matter whether you do "produce (if test a else b)" or "if test (produce a) else (produce b)".

Example:

var x = [ if (test) 1 else 2 ];

Here it's ambiguous syntax, but the behaviors of the two options are indistinguishable.

We'd obviously have to go through all the syntax corners to make sure there are no cases I have missed.

[Cat-sushi]

Note: This issue is not for collection-if. Please discuss it at #729 or post a new issue.

[lrhn]

The issue with collection-if here is that expressions occur in collections too, so there is some amount of syntactic overlap/ambiguity if expression-if starts using the same syntax. There is no need to change collection-if, and as stated this issue is not about doing so anyway, but changing expression-if interacts with collection-if, and that interaction needs to be discussed. (As stated above, I believe that interaction and ambiguity to be not-too-problematic).

It's true that removing ?/: syntax will free up some syntax that is otherwise causing us problems with syntactic ambiguity, and using a prefix if will definitely work instead.

The options are really:

 <expression> ::= `if` `(` <expression> `)` <expression> `else` <expression>

or

 <expression> ::= `if` `(` <expression> `)` <expression> (`else` <expression>)?

Anything else will just be inconsistent.

Since expressions must evaluate to a value or throw, omitting the else branch means that the omitted branch needs a default semantics.
The three obvious options are:

1. Do not allow omitting it.
2. Evaluate to null
3. Throw.

The first one is what we currently do for ?/:. It also avoids ambiguity in if (t1) if (t2) e1 else e2 - which if does the else bind to? We solved it for statements, so we'd do the same thing for expressions, but it's a place where users can write code that doesn't do what they think.

The second one is adding null values, and it becomes ambiguous when an if occurs in a collection: Interpreted as an expression-if, it would add null to the collection, interpreted as a collection-if it adds nothing. So, not particularly useful.

Throwing means that it's effectively an error, and we should probably have gone with not allowing it anyway. Not practically useful.

So, my vote would be on requiring an else branch.

Ob-pedantry: The ?/: operator is not the ternary operator. It is the conditional (expression) operator which is a ternary operator (takes three operands).

[Cat-sushi]

The issue with collection-if here is that expressions occur in collections too, so there is some amount of syntactic overlap/ambiguity if expression-if starts using the same syntax.

I understand.

So, my vote would be on requiring an else branch.

I would also vote on requiring else branch. (The first title of this issue was "... mandatory else-part")

A syntax clean braking from if-statement and collection if is also attractive for me.

[Cat-sushi]

@tatumizer null doesn't necessarily mean omitting argument, so your proposal require special syntactical treatment which could be called if-argument. If-argument which doesn't exist now make discussions more comprecated. I'd like to discuss deprecating ?/:.

[Cat-sushi]

I prefer if(a, b, c) as conditional expression, so far. It is a little confusing because it start with if(, but it's syntax is not ambiguous.
Is it feasible?

[lrhn]

Using if (e1, e2, e3) is technically feasible. I personally think it's too far from the existing syntax to be preferable.
One design rule is that similar things should look similar, different things ahould look different.
This looks like a function call, but isn't. That's not unprecedented (assert is also not a function call), but it is one argument against. It would make the conditional expression easily delimited and easier to parse. It might confuse users coming from JavaScript, where you have the comma operator, and if (a, b, c) means if (c) after evaluating a and b for their side effects.

I can see the reasoning for "optional arguments". A non-else-condition in an optional argument position could mean not passing the argument, but currently it would only work for named optional parameters. Omitting a positional parameter would shift the remaining arguments up, which is not sound in general. If we had a way to omit optional arguments in the middle of a positional parameter chain, then it would fit better (not shift later arguments up, but still trigger default value in the function). That's a different feature.

[Cat-sushi]

Is comma operator in JavaScript or C populer for modern language like Dart?
Anyway, I would also like see clearer syntax for conditional expression than f(a, b, c).

[Cat-sushi]

What do you think about if(a : b : c)?

[Cat-sushi]

@tatumizer
Set literal is one of the major reasons which makes the discussion #376 complicated. AFAIK, Set literal was newly introduced on 27th February by demand from the Flutter team, but the Flutter framework uses only type specified Set literals. So, deprecating Set literal without type argument might be feasible, but it is another breaking change, any way.

As I mentioned in the Motivation, non-affinity between NNBD and ? of current conditional expression is the cause of problems, but not Set literal, and it is the reason why I rename this issue to "deprecating ternary operator ?/:".

if(a : b : c) as conditional expression can be discussed without worry about the Set literal problem.