Implementing equality would be made tedious again if we lose this. ``` enum Jams : Equatable {
case dmsr(Bool) case kiss(Bool, Bool) case pheromone(Int, Bool, Int) public static func ==(lhs:Jams, rhs:Jams) -> Bool { switch (lhs, rhs) { case let (.dmsr(left), .dmsr(right)): return left == right case let (.kiss(left), .kiss(right)): return left == right case let (.pheromone(left), .pheromone(right)): return left == right case (.dmsr, _), (.kiss, _), (.pheromone, _): return false } } } ``` On Sun, Jan 22, 2017 at 4:51 AM, Robert Widmann via swift-evolution < 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) which you use something like this > with other non-trivial enums (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. > > ~Robert Widmann > > 2017/01/22 3:02、Daniel Duan <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> > 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> > のメッセージ: > > > On Jan 19, 2017, at 2:58 PM, Daniel Duan <dan...@duan.org> wrote: > > > > On Jan 19, 2017, at 2:29 PM, Joe Groff <jgr...@apple.com> wrote: > > > > On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution < > 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 > 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