- Parse: Has to account for the inclusion of tuple shuffles whenever it parses 
patterns (see the switch-statement example in the proposal)
- 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 
<https://bugs.swift.org/browse/SR-4715>.  Tuple shuffles are also allowed to 
reorder around variadic arguments which makes matching that much more difficult.
- 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.

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 
> <[email protected]> wrote:
> 
> 
>> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution 
>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to