[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[L. Mihalkovic]

> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>>> 
>>> guard
>>> x == 0 && a == b && c == d &&
>>> let y = optional, w = optional2, v = optional 3 &&
>>> z == 2
>>> else { ... }
>>> 
>>> Figuring out where to break the first line into expression and into condition (after the `d`) could be very challenging to the compiler.
>> 
>> I'm not sure it is. `let` and `case` are not valid in an expression, so an `&&` followed by `let` or `case` must be joining clauses. On the other side of things, Swift's `&&` doesn't ever produce an optional, so if we're parsing an expression at the top level of an if-let, an `&&` must indicate the end of the clause. An if-case *could* theoretically include an `&&`, but pattern matching against a boolean value seems like a fairly useless thing to do in a context that's specifically intended to test booleans.
> 
> Let me answer in another way that speaks to my background which isn't in compiler theory: The use of && may produce cognitive overload between the use in Boolean assertions and the use in separating condition clauses.
> 

+1  the focus is should not transfer from the conditions to the separator which happens to me with &&

I hope the core team pulls rank, even recasting this as adressing a bug in the original grammar, to push it in. Worst case scenario is people ignore it until they start needing it.


> -- E
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution