In English (and, I'm guessing, many other languages), semicolons are used
as a second 'tier' of separators when commas become ambiguous. I'm puzzled
that a proposal to bring this longstanding convention to Swift is raising
so many objections, even going so far as to prompt alternatives such as
this that break clearly useful shorthands.
On Tue, May 31, 2016 at 10:44 David Hart via swift-evolution <
swift-evolution@swift.org> wrote:
> Yet another alternative: would it be possible to disallow commas as
> variable declaration separators and use them for condition clause
> separators again:
>
> let a = 4, b = 8 // becomes illegal and requires to separate them on two
> lines
>
> if a > 4, let c = foo(), let d = bar(), c != d { // now comma is not
> ambiguous anymore
> }
>
> David.
>
> On 28 May 2016, at 02:30, 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.
>
> -- 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
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
