<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- Parse: Has to account for the inclusion of tuple shuffles whenever it parses patterns (see the switch-statement example in the proposal)</div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- 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 - <a href="https://bugs.swift.org/browse/SR-4715" class="">something we should be doing even today</a>. Tuple shuffles are also allowed to reorder around variadic arguments which makes matching that much more difficult.</div></div></div></blockquote><div><br class=""></div>The type-checker doesn't have to do this with argument-matching. It might do it anyway, but it doesn't have to.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">- 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.</div></div></div></blockquote><div><br class=""></div>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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">~Robert Widmann</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="">On May 4, 2017, at 10:35 PM, Tony Arnold via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Why?<br class=""></blockquote><br class="">Not trying to be smart, but the reasoning is in Robert’s proposal:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Their inclusion in the language complicates every part of the compiler stack, uses a syntax that can be confused for type annotations (<a href="https://twitter.com/CodaFi_/status/860246169854894081" class="">https://twitter.com/CodaFi_/status/860246169854894081</a>), contradicts the goals of earlier SE's (see SE-0060), and makes non-sensical patterns possible in surprising places.<br class=""></blockquote></blockquote><br class=""><br class="">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?<br class=""><br class="">====<br class=""><br class="">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…<br class=""><br class=""><br class="">Tony<br class=""><br class=""><br class="">----------<br class="">Tony Arnold<br class="">+61 411 268 532<br class=""><a href="http://thecocoabots.com/" class="">http://thecocoabots.com/</a><br class=""><br class="">ABN: 14831833541<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>