[swift-evolution] Revisiting SE-0110

[Mark Lacey]

> On May 25, 2017, at 11:27 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution