> On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution > <swift-evolution@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. > - 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. 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@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 5 May 2017, at 12:27, Félix Cloutier via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@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 >>>> <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/ <http://thecocoabots.com/> >> >> ABN: 14831833541 >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
