<div style="white-space:pre-wrap">Perhaps, but it is a much bigger change and a different proposal topic entirely. Given how variable declarations work now, Erica's proposed syntax to replace where clauses is the most elegant solution, IMO.<br></div><br><div class="gmail_quote"><div dir="ltr">On Sat, May 28, 2016 at 04:15 Goffredo Marocchi via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This I would not cry about. In other languages they are more of a source of pain than anything else.<br>
<br>
Sent from my iPhone<br>
<br>
> On 28 May 2016, at 09:10, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> Yet another alternative: would it be possible to disallow commas as variable declaration separators and use them for condition clause separators again:<br>
><br>
> let a = 4, b = 8 // becomes illegal and requires to separate them on two lines<br>
><br>
> if a > 4, let c = foo(), let d = bar(), c != d { // now comma is not ambiguous anymore<br>
> }<br>
><br>
> David.<br>
><br>
>>> On 28 May 2016, at 08:25, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>>><br>
>>> 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.<br>
>><br>
>> Yes, which is quite intentional on my part. The `if` statement requires that all of its clauses succeed; if pattern matching and optional testing were boolean expressions, you would use `&&` to link them with each other and with boolean tests. The fact that these are *not* boolean expressions is a mere artifact of Swift's implementation.<br>
>><br>
>> I think our best solution is to make Swift act as though these *are* boolean expressions, but ones that can only be used in a limited way: they can only be `&&`ed, because they bind variables that have to be made available in specific blocks. In other words, I think we should paper over the compiler limitations preventing these things from working as expected.<br>
>><br>
>> (Actually, it might be interesting to allow `!let` and `!case` statements which are available in the `else` branches of the control structures they're used in, but that's a different story...)<br>
>><br>
>> ***<br>
>><br>
>> If you'll permit me to go sort of "mad dream" here for a moment, I can actually sort of see a way to do a lot of this in the standard library. Imagine if the `let` and `case` clauses in a conditional produced a type like this:<br>
>><br>
>> enum PatternMatchingResult<BoundValues> {<br>
>> case failed<br>
>> case succeeded (BoundValues)<br>
>> }<br>
>><br>
>> `BoundValues` would be the values, if any, extracted through the pattern matching operation. Then you could define operators like these:<br>
>><br>
>> func && <T, U>(lhs: PatternMatchingResult<T>, rhs: @autoclosure () -> PatternMatchingResult<U>) -> PatternMatchingResult<(T, U)> {<br>
>> guard case .succeeded (let lhsValue) = lhs else {<br>
>> return .failed<br>
>> }<br>
>> guard case .succeeded (let rhsValue) = rhs() else {<br>
>> return .failed<br>
>> }<br>
>> return .succeeded (lhsValue, rhsValue)<br>
>> }<br>
>><br>
>> func && <T>(lhs: PatternMatchingResult<T>, rhs: @autoclosure () -> Boolean) -> PatternMatchingResult<T> {<br>
>> guard case .succeeded = lhs else {<br>
>> return .failed<br>
>> }<br>
>> guard rhs() else {<br>
>> return .failed<br>
>> }<br>
>> return lhs<br>
>> }<br>
>><br>
>> func && <U>(lhs: Boolean, rhs: @autoclosure () -> PatternMatchingResult<U>) -> PatternMatchingResult<U> {<br>
>> guard lhs else {<br>
>> return .failed<br>
>> }<br>
>> return rhs()<br>
>> }<br>
>><br>
>> And then transform this:<br>
>><br>
>> guard<br>
>> x == 0 && a == b && c == d &&<br>
>> let y = optional, w = optional2, v = optional 3 &&<br>
>> z == 2<br>
>> else { ... }<br>
>><br>
>> Into something like this (where `?` is a sort of "anonymous capture slot"):<br>
>><br>
>> guard case let .success (y, w, v) = (<br>
>> x == 0 && a == b && c == d &&<br>
>> Pattern(.some(?), .some(?), .some(?)).result(ofMatchingAgainst: (optional, optional2, optional3)) &&<br>
>> z == 2<br>
>> )<br>
>> else { ... }<br>
>><br>
>> Resolving to:<br>
>><br>
>> guard case let PatternMatchingResult.success (y, w, v) = (<br>
>> (&&)( // (Boolean, PatternMatchingResult) -> PatternMatchingResult<br>
>> x == 0,<br>
>> (&&)( // (Boolean, PatternMatchingResult) -> PatternMatchingResult<br>
>> a == b,<br>
>> (&&)( // (Boolean, PatternMatchingResult) -> PatternMatchingResult<br>
>> c == d,<br>
>> (&&)( // (PatternMatchingResult, Boolean) -> PatternMatchingResult<br>
>> Pattern(.some(?), .some(?), .some(?)).result(ofMatchingAgainst: (optional, optional2, optional3)),<br>
>> z == 2<br>
>> )<br>
>> )<br>
>> )<br>
>> )<br>
>> )<br>
>> else { ... }<br>
>><br>
>> The `Pattern` type shown here is notional, not an actual thing that would exist as a first-class entity—although that *would* be rather nice to have eventually...<br>
>><br>
>> --<br>
>> Brent Royal-Gordon<br>
>> Architechies<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>