> On May 25, 2017, at 3:16 PM, Mark Lacey <[email protected]> wrote:
>> On May 25, 2017, at 11:27 AM, John McCall via swift-evolution
>> <[email protected]> wrote:
>>
>>> On May 25, 2017, at 2:23 PM, Nevin Brackett-Rozinsky via swift-evolution
>>> <[email protected]> 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
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
