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 (TypeLift · GitHub
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 <daniel@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.codafi@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 <daniel@duan.org> wrote:
On Jan 19, 2017, at 2:29 PM, Joe Groff <jgroff@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