> On Jan 22, 2017, at 8:30 AM, Tony Allevato via swift-evolution > <[email protected]> wrote: > > Which is another reason we should be auto-deriving Equatable. > > Couldn't variation generics help here? If someone wanted to capture the whole > argument list as a single tuple, we could require that they do it as a > parameter pack? It's essentially the inverse of the tuple splat already > mentioned in that section of the generics manifesto.
Yeah, I agree that the lack of auto-derived Equatable is the real problem here. It would also definitely make sense to include variadic patterns as part of a future variadic generics design. -Joe > On Sun, Jan 22, 2017 at 7:42 AM T.J. Usiyan via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > 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 > <[email protected] <mailto:[email protected]>> 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. > > ~Robert Widmann > > 2017/01/22 3:02、Daniel Duan <[email protected] <mailto:[email protected]>> のメッセージ: > >> 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 <[email protected] >>> <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> のメッセージ: >>> >>>> >>>>> On Jan 19, 2017, at 2:58 PM, Daniel Duan <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>>> On Jan 19, 2017, at 2:29 PM, Joe Groff <[email protected] >>>>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>>> >>>>>>> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >>>>>>> <[email protected] <mailto:[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] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
