> On May 25, 2017, at 11:27 AM, John McCall via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution
>> <swift-evolution@swift.org> wrote:
>> One possibility is to make parentheses consistently meaningful in closure
>> argument lists, so that “(a, b)” would exclusively mean “there is one
>> parameter of tuple-type, which is being destructured”, while “a, b” without
>> parentheses would exclusively mean “there are two parameters”.
>>
>> That way you can destructure a tuple parameter if you wish (by using
>> parentheses) or you can leave the tuple intact (by listing a single
>> identifier without parentheses).
>
> The problem with this is that we also need some way to be explicit about the
> return type, and it would be strange to allow (and require!)
> { a, b -> Int in }
> when that's not at all a valid way to write a function type
This is allowed today, but I agree it would be very strange to require it.
We also allow:
{ (a, b: Int) -> Int in } // infer ‘a' from context
and
{ (a, b: () -> Int) -> Int in } // infer ‘a' from context
but these become completely ambiguous if you remove the parens.
> . Also it would be an enormous source break, even worse than this problem.
Yes.
> That said, I'm quite sympathetic to the idea that directly destructuring
> tuples in closure parameter lists is too useful to lose, even if it's
> ambiguous.
I think the right thing to do here is add uniform tuple destructuring in
functions, but that is clearly out of scope for 4.0.
Reverting SE-0110 is not as simple as reverting a single change. So far I have
found 19 commits that addressed different aspects moving from the old behavior
by searching for SE-110 and SE-0110 in commit logs. It is possible there were
others that did not specifically call out the proposal.
Having said that, we are supposed to support the old behavior for
"-swift-verison 3", so it may be possible to find the handful of places where
the version check can be removed and old behavior restored under "-swift-verson
4" if we choose to do that as mitigation until the destructuring feature is
properly designed and implemented.
Another option is attempting to do some targeted fix specifically for closure
arguments but that does not seem straightforward, and does seem relatively
risky.
Mark
>
> John.
> _______________________________________________
> 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
