[swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Daniel Duan]

Daniel Duan
Sent from my iPhone
> On Feb 27, 2017, at 10:00 AM, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Feb 24, 2017, at 9:26 PM, Daniel Duan <daniel at duan.org> wrote:
>> 
>> Before I start revising this proposal, there are a couple of open questions I’d like to discuss with the community and the core team.
>> 
>> The first question relates to the purpose of having a “internal” argument name. There are applications of such names in GADT (if we ever get there) and perhaps the case-as-subtype-of-the-enum stories on the list right now. Out side of these scenarios, however, such names has few chances to be used. The one I can come up with, which is also the “open” part of the question, is this: we can use the internal names in pattern matching, as opposed to using the labels. This seems to align with the subtyping/GADT use cases. Is this a desirable outcome?
> 
> Why would GADTs make internal argument names useful? They seem completely useless to me. Their "internal"-ness is compromised if you try to hang semantics off of them—they shouldn't have any impact on use sites.

Interesting. 

I was reaching for any possible use cases there. The theory is these names would be how one refers to a "property" of the case in, say, extension methods for the case.

But yeah, I considered this internal name thing during first draft and decided that they weren't necessary 🤷‍♀️
> 
>> The second open question is the syntax for “overloaded” cases. If we decide to allow them, what should the patterns matching them look like? I can think of one obvious-ish design where we make the pattern look like the declaration and require types for disambiguation. So the most verbose form of pattern would look something like
>> 
>> ```
>> case let .baseName(label0 name0: Type0, label1 name1: Type1)
>> ```
> 
> By "overloaded", do you mean "same name different types", or "same base name, different argument names"? I think we should have a consistent naming model where the latter is never considered overloading.

Same name different type is what "overloading" was meant here. "Same base name" is already in the first revision and wouldn't fit in this "open question" discussion.

> As an affordance to make pattern matching more concise, it seems reasonable to me to maybe say that a binding pattern matches a label with the same name, so that `case .foo(let bar, let bas)` can match `.foo(bar:bas:)`.

Good idea.

> -Joe