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

John McCall rjmccall at apple.com
Mon Feb 27 12:53:49 CST 2017


> On Feb 27, 2017, at 1:39 PM, Daniel Duan <daniel at duan.org> wrote:
>> 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 🤷‍♀️

I think the strongest argument here is that internal names already have an accepted meaning, which is just that they name the argument variables in the following code.  Today, cases don't have any following code, but if/when we add that in SE-9999, people will obviously expect internal names to name those argument variables.  Even if the SE-9999 proposers decide that, actually, using internal names for case arguments isn't a good idea, they will still need to do something about that natural user expectation, and they shouldn't be limited by us having carelessly given internal names some random other meaning way back in SE-0155.

John.

>> 
>>> 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
> 



More information about the swift-evolution mailing list