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 <[email protected]> のメッセージ: > >> On Jan 19, 2017, at 2:58 PM, Daniel Duan <[email protected]> wrote: >> >> >>>> On Jan 19, 2017, at 2:29 PM, Joe Groff <[email protected]> wrote: >>>> >>>> >>>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >>>> <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
