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

[Matthew Johnson]

> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 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.

I like this terminology.  I’ll start using it.  Thanks for making an attempt to get everyone on the same page!  :)

> 
>> 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
> terminology.
> 
>> 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:)`.
> 
> SGTM
> 
> -- 
> -Dave
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution