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

[Robert Widmann]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170122/bd22109c/attachment.html>