[swift-evolution] [Proposal][Discussion] Deprecate Tuple Shuffles

[Robert Widmann]

~Robert Widmann

2017/05/05 14:07、John McCall <rjmccall at apple.com> のメッセージ:

>> On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org> wrote:
>> - Parse: Has to account for the inclusion of tuple shuffles whenever it parses patterns (see the switch-statement example in the proposal)
> 
> This example doesn't make any sense.  Tuple shuffles are not responsible for the rule that you cannot match an unlabelled tuple with a labelled tuple pattern.  I'm really not sure what you think this would do, anyway; it's not like tuple pattern element labels are lexically available.
> 

Exactly. I've since removed this example.  My initial confusion was around the labeled matching being a thing at all. 

>> - Sema: Has to perform argument matching by computing these tuple shuffle mappings thereby complicating the solver and the parts of solution application.  Really, the only place this has a valid use is in the error handling path where we can use the tuple shuffle to emit a fixit that properly reorders arguments - something we should be doing even today.  Tuple shuffles are also allowed to reorder around variadic arguments which makes matching that much more difficult.
> 
> The type-checker doesn't have to do this with argument-matching.  It might do it anyway, but it doesn't have to.
> 
>> - SIL: Has to account for tuple shuffles in multiple places.  One notable one is that SILGen has to support two different paths when lowering tuple shuffles - one for variadic shuffles and the other for “normal” shuffles.  Each path supports a different subset of the features necessary to implement the full feature that is tuple shuffles, neither can really be simplified down to a common core in their current iteration.
> 
> Call argument emission needs to deal with something like this anyway.  But yes, we could eliminate the redundant path for ordinary r-value tuple emission.
> 
> I'm not saying any of this to kill this proposal, just to clarify that the complexity costs aren't as high as you seem to be saying.
> 
> John.
> 
>> If you want some numbers, I spent the evening removing them from the codebase and came up with a win of about 1500 LoC.  Each line of code supporting a feature that people aren’t actually using.
>> 
>> ~Robert Widmann
>> 
>> 
>>>> On May 4, 2017, at 10:35 PM, Tony Arnold via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Why?
>>> 
>>> Not trying to be smart, but the reasoning is in Robert’s proposal:
>>> 
>>>>> Their inclusion in the language complicates every part of the compiler stack, uses a syntax that can be confused for type annotations (https://twitter.com/CodaFi_/status/860246169854894081), contradicts the goals of earlier SE's (see SE-0060), and makes non-sensical patterns possible in surprising places.
>>> 
>>> 
>>> Robert, maybe you could include some detail about how this feature is complicating the compiler stack, and what will be improved by it’s removal?
>>> 
>>> ====
>>> 
>>> That being said, I’m all for you guys making your lives easier at the cost of something we shouldn’t be using in the first place…
>>> 
>>> 
>>> Tony
>>> 
>>> 
>>> ----------
>>> Tony Arnold
>>> +61 411 268 532
>>> http://thecocoabots.com/
>>> 
>>> ABN: 14831833541
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/1ff777e0/attachment.html>