[swift-evolution] Revisiting SE-0110

[John McCall]

> On May 25, 2017, at 3:16 PM, Mark Lacey <mark.lacey at apple.com> wrote:
>> 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.

I suppose I should have tested that. :)

> 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.

Yeah, I think we need to stick with allowing 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.

The non-closure aspects of this would not be difficult.  All the complexity is in deciding what to do with closures.

> 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.

Oh, that's an interesting option.

> Another option is attempting to do some targeted fix specifically for closure arguments but that does not seem straightforward, and does seem relatively risky.


John.

> 
> Mark
> 
> 
>> 
>> John.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>