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
> <[email protected]> wrote:
>
>>
>> On May 27, 2016, at 6:26 PM, Brent Royal-Gordon <[email protected]>
>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
