> On Jan 22, 2017, at 11:26 AM, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Jan 22, 2017, at 3:51 AM, Robert Widmann via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Sure. One of the first gadgets I wrote was a way of destructuring an array >> into a familiar cons-list kind of enum >> (https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9 >> <https://github.com/typelift/Basis/blob/master/Basis/Array.swift#L9>) which >> you use something like this with other non-trivial enums >> (https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161 >> >> <https://github.com/typelift/Valence/blob/cf4353c64de93b98c460529b06b8175c9ecfb79b/Tests/SystemF.swift#L161>). >> >> It's not strictly a problem for me to lose this feature, but it is gonna be >> a bit weird if we lose recursive match but also allow it for just plain old >> tuple patterns. > > We’re not discussing taking away recursive match are we? IIUC the discussion > is limited to taking away matching all associated values as a single tuple, > rather than matching each value individually.
Correct. >> >> ~Robert Widmann >> >> 2017/01/22 3:02、Daniel Duan <dan...@duan.org <mailto:dan...@duan.org>> >> のメッセージ: >> >>> FWIW, in all public Github repos with 5k+ stars whose language gets >>> recognized as “Swift”, 576 enum cases has associated values and among them >>> 55 has 2 values or more. After some very casual grepping I didn’t find a >>> lot of usage of this particular pattern. >>> >>> Care to share some examples, Robert? >>> >>> - Daniel Duan >>> >>>> On Jan 21, 2017, at 11:00 PM, Robert Widmann <devteam.cod...@gmail.com >>>> <mailto:devteam.cod...@gmail.com>> wrote: >>>> >>>> I find myself doing this a lot, but maybe my problems are just more >>>> Algebra-shaped than most. That said, I appreciate this cleanup and lean >>>> +1 (because you mentioned a way to partly keep this behavior). >>>> >>>> ~Robert Widmann >>>> >>>> 2017/01/19 18:14、Joe Groff via swift-evolution <swift-evolution@swift.org >>>> <mailto:swift-evolution@swift.org>> のメッセージ: >>>> >>>>> >>>>>> On Jan 19, 2017, at 2:58 PM, Daniel Duan <dan...@duan.org >>>>>> <mailto:dan...@duan.org>> wrote: >>>>>> >>>>>> >>>>>>> On Jan 19, 2017, at 2:29 PM, Joe Groff <jgr...@apple.com >>>>>>> <mailto:jgr...@apple.com>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>>>>> >>>>>>>> This looks totally reasonable to me. A couple of comments: >>>>>>>> >>>>>>>> 1) Because this proposal is breaking the link between the associated >>>>>>>> value of an enum case and tuple types, I think it should spell out the >>>>>>>> rules that switch statements will use when matching an enum value >>>>>>>> against a a case with an associated value. Some kind of rules fell out >>>>>>>> of them being treated as tuple types, but they might not be what we >>>>>>>> want. >>>>>>> >>>>>>> I was about to bring up the same. Right now, an enum pattern works like >>>>>>> .<identifier> <tuple-pattern>, where the <tuple-pattern> then >>>>>>> recursively matches the payload tuple. In this model, it seems like >>>>>>> we'd want to treat it more like .<identifier>(<pattern>, <pattern>, >>>>>>> ...). Similar to how we lost "tuple splatting" to forward a bunch of >>>>>>> arguments, we'd have to decide whether we lose the ability to match all >>>>>>> parts of the payload into a tuple. >>>>>> >>>>>> I’m leaning towards “no” for simplicity of the language (and >>>>>> implementation). That means this would be source-breaking 😞. Will >>>>>> update the proposal and see how the rest of the feedback goes. >>>>> >>>>> It'd be a good idea to try to find examples of people doing this out in >>>>> the wild too, to see how widespread it is as well as how onerous the >>>>> workarounds for losing the feature would be. >>>>> >>>>> -Joe >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto: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
