[swift-evolution] [draft] Compound Names For Enum Cases

[Tony Allevato]

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.
On Sun, Jan 22, 2017 at 7:42 AM T.J. Usiyan via swift-evolution <
swift-evolution at swift.org> 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 <
> swift-evolution at 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 <daniel at 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 at 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 at swift.org>
> のメッセージ:
>
>
> On Jan 19, 2017, at 2:58 PM, Daniel Duan <daniel at duan.org> wrote:
>
>
>
> On Jan 19, 2017, at 2:29 PM, Joe Groff <jgroff at apple.com> wrote:
>
>
>
> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170122/dba685e2/attachment.html>