~Robert Widmann
2017/05/05 14:07、John McCall <[email protected]> のメッセージ: >> On May 4, 2017, at 10:52 PM, Robert Widmann via swift-evolution >> <[email protected]> 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 >>>> <[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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
