> On May 28, 2016, at 2:30 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > >>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon <br...@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@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution