Control Flow Collections

[munificent]

In order to handle conditionally omitting elements from list literals (#62, #70), I propose that we allow if and for inside list and map literals.

Feature specification draft.

This issue is for discussing that proposal.

Edit: The proposal has been accepted as is being implemented. The implementation work is tracked in #165.

[mraleph]

Two questions:

• Is there a reason for not make it more uniform and allow switch too?
• Should we also allow if and switch outside of list literals in the expression context?

Seems a bit arbitrary and confusing to newcomers that the first like would be allowed and the second one would require conditional operator

var x = [if cond expr else expr].first;
var y = if cond expr else expr;

[lrhn]

My answers to those two questions:

• The reason to not allow while/do-while is that this is not imperative code, it's iterative and conditional code. That doesn't rule out switch, but it would change each case expression to be a single "element expression" with no break. That's far from the current switch syntax, IMO farther than the for/if cases. Nothing prevents you from doing () { switch ( ... ) case .... return ...; }() if you want an arbitrary statement.

• I don't see if (cond) expr else expr as the common case for a literal element expression, rather the real use-case is conditional omission, if (cond) expr. You can already use ?: for choice. If we weren't planning spreads I would have preferred to not even allow the else for element expressions. With spreads, it does make sense to do if (test) ...[e1, e2] else ...[e3, e4, e5] since you a have a different amount of elements in the branches (you can do that with if (test) for .... else for ... as well, it's just not as readable, but ... iterable is equivalent to for (var x in iterable) x, so that's hardly surprising).

We could use if for expressions conditionals too, but we already have ?:, and I'd loathe to have two ways to do the same thing, where neither is inherently superior.
If we were designing the language from scratch, I'd be much more receptive to using if for expressions and never add ?:. We are not.

[munificent]

@lrhn said it well.

The other practical reason for not doing switch was that I didn't see any places in the corpus I examined where it seemed like it would be valuable.

Allowing if as an expression in general is interesting, but that's a bigger feature with more subtle implications. It immediately raises questions of if everything should be an expression and that opens a whole can of complexity given Dart's existing syntax and semantics. It would have been nice to do before 1.0, but I think would be very challenging now.

[mraleph]

While we are not designing our language from scratch we are trying to attract more new users to the language - and they are learning the language from scratch.

Put yourself in their shoes and ask yourself if this makes sense to you:

var x = [if cond expr else expr].first;  // ok
var y = if cond expr else expr;  // not ok
var z = cond ? expr : expr; // ok
var a = [cond ? expr : expr] // ok, but we suggest this can be converted to if

Cause it does not make sense to me. It makes this feature non-orthogonal - where it could easily be made orthogonal without any significant implications AFAIK.

If we make it so non-orthogonal - then we can at least make our tools produce meaningful errors, because currently it is not handled very well

(Note that DartPad's analyzer happily parses this code - while CFE reports compilation errors)

Regarding the switch: this feature is requested quite often and modern language actually do have it, including Java (see http://openjdk.java.net/jeps/325 - which provides very good rationale to have it).

Again - adding switch makes the feature feel more complete, more orthogonal.

[munificent]

where it could easily be made orthogonal without any significant implications AFAIK.

I think the main implication of making if an expression is that users will likely expect to be able to use blocks as the then and else statements. We'd either have to make that a surprising error (surprising since the style guide requires you to use blocks in almost all cases for if statements) or we'd have to allow blocks as expressions too, which I think does open the whole "everything is an expression" can of worms.

[mraleph]

I think the main implication of making if an expression is that users will likely expect to be able to use blocks as the then and else statements.

Would not users similarly expect to use blocks when if starts appearing in the lists?

When I see [if (x) x else y ] I actually think that if is allowed here because it is an expression, not because it is some weird list-literal specific thing.

The error that you would need to implement for [if (x) { x; y; z; } else { a; b; c; }] is exactly the same kind of error you would implement for var o = if (x) { x; y; z; } else { a; b; c; }.

I think the only unpleasant and hard to explain corner case here is the interpretation of [if (x) a] which is not an error while var v = if (x) a is an error. I think we could interpret as [if (x) a else _|_] and say that bottom value is not allowed in other contexts.

[lrhn]

I actually believe that users will be able to distinguish collection comprehension for/if syntax from statement for/if syntax. If I didn't think that, I would not be in favor of reusing the syntax.

I had the same worries initially, but I actually got to the point where it felt natural.

It's arguable that we now have "similar syntax for different meanings", but what we have is actually
similar syntax for similar meanings, it's just that conditions/iterations are parameterized by the syntactic category that they apply to.

When used as a a statement, for (...) and if (...) allow a statement as their body.
When used as a list element, for (...) and if (...) allow a list element as their body.
When used as a map entry, for (...) and if (...) allow a map entry as their body.

Apart from that, they actually work exactly the same, performing iteration or choice at run-time. Since all the contexts have the notion of repetition and of doing/adding nothing, or doing/adding more than one thing, we can use both iteration and the if-with-no-else.

For expressions, that does not apply. An expression has one result, and it always has a result if it terminates normally. That's why neither repetition nor one-or-none conditions apply to expressions, and why we should not try to extend if to expressions. Not because we couldn't, but because that would be similar syntax for a different behavior (no else-less if in expressions, no for loops at all).

So, I do think the proposed syntax is consistent with the existing language, and allowing if in expressions is not.

(That does not explain why we can't have try/catch in literals. The switch/case makes sense, but only if we remove the requirement for break, and do?/while won't work well because they generally rely on the body to do the iteration.)

[munificent]

Would not users similarly expect to use blocks when if starts appearing in the lists?

I am somewhat worried about that (the proposal mentions this as a concern), but I think it's less of a worry because users do understand they are inside the context of a list and that's a pretty explicitly "not statement" place. Something like this feels more ambiguous to me:

var foo = if (condition) {
   ...
} else {
  ...
}

Yes, technically the initializer is strictly an expression so it's definitely not a statement context, but it does look a lot like one.

Again - adding switch makes the feature feel more complete, more orthogonal.

The syntax for switch is already bad: weird label-looking things, mandatory break, fall-through, etc. I strongly believe we shouldn't make switch more complex. It's primary value in Dart is that it works identical to switch in other languages which eases porting and learning. Anything we add to switch to make it "better" worsens those attributes

If we want to make a "better switch" (and I do), I think we should add a separate new pattern-matching syntax that removes all of the warts of switch, allows destructuring, works on user-defined types, etc. If we do that, then I think it's reasonable to consider making it an expression and/or allowing it as a control flow element in a collection.

More pragmatically: switch just isn't used that often and I couldn't find any examples in the corpus I looked at where allowing switch inside a collection literal would be useful.

[gamebox]

It seems that outside of the context of constructing a collection literal, the die has been cast for if. A match expression as described by @munificent would cause the least confusion and surprises, and allow for cleaning up ugly initializing code(namely values that are only assigned once not being able to be const due to initialization happening in the if statement.

Now as far as far as the specification under question is concerned, is function application allowed within the context of an if or for, i.e. a function that returns a valid collection member? This would be interesting as it would create a bit of a discrepancy between using this feature with lists vs maps (or is there some value that could be returned as a valid member for a map from a function?). Obviously some languages with tuples allow lists of 2-tuples to be spread into a map. Sidenote: Are tuples on anyone's radar?

[lrhn]

A function application is allowed for list literals, because a function application is an expression, and a list element is an expression.

In a map literal, the entry is a key:value pair, which is not a normal expression, nor is it an expressible value. You literally has to write "expression-colon-expression" to be a map entry. (You can perhaps write ... functionCallReturningMap() instead, because maps are expressible values).

[munificent]

Now as far as far as the specification under question is concerned, is function application allowed within the context of an if or for, i.e. a function that returns a valid collection member?

Yes, any expression is allowed there, including a function call.

(You can perhaps write ... functionCallReturningMap() instead, because maps are expressible values).

That's right. You could spread a map into it:

var a = {1: 2, 3: 4};
var b = {
  5: 6,
  if (condition) ...a
};

[kmillikin]

Hi @munificent, this looks very nice.

I don't think we should allow general if and for expressions. It's so non-obvious what they mean that it's better not to introduce them at all and there are pretty simple workarounds for where you'd use them. (What is the value of an if with no else and a false condition? What if it's a non-nullable type? Runtime error? What is the value of a for loop? The last value? The rest are evaluated for their side effects?)

The runtime semantics needs one more pass through it. Here are some things I spotted to clarify:

1. What is the scoping of the variable bound by for elements? To avoid surprises it should probably be the same as for statements.

2. Elements are evaluated but not added to the collection in all cases.

3. A semantics in terms of adding to a collection does not work for a const collection.

I'll sketch up what this would look like as a Dart-to-Dart (actually Kernel) transformation. I'd like to see if we could come up with an operational and static semantics that says it behaves as if ... to explicitly bless such an implementation technique.

Notice that for elements gives you let for local variables through an encoding (without closures) which is kind of new.