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

Dave Abrahams dabrahams at apple.com
Mon Feb 27 16:07:52 CST 2017

on Mon Feb 27 2017, 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? 

I'll probably never win this fight, but I'm trying to get people to use
“parameter name” and “argument label” as the preferred terms.

> 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.
>> 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"? 

When you write "argument name," do you mean parameter name or argument
label?  This is an example of why I'd like us to settle on the other

> I think we should have a consistent naming model where the latter is
> never considered overloading. 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:)`.



More information about the swift-evolution mailing list