<div dir="ltr">Having watched this conversation from the sidelines, I just wanted to chime in from a more distant view:<div><br></div><div>Originally, I thought this proposal was very nice because it made a good argument as to why enum cases would benefit from being function-like. It follows naturally that form should follow function, and therefore it's hard to argue that the syntax shouldn't be "rectified."</div><div><br></div><div>But, given the latest discussions, it seems that there's a bunch of round-peg-square-hole efforts going on precisely because enum cases *aren't* very function-like in some key respects:</div><div><br></div><div>- John McCall gives a cogent reason why parameter names and argument labels would be inconsistently used if they are put to the purpose that some have proposed here for enum cases.</div><div><br></div><div>- There's a lot of bikeshedding as to pattern matching with argument labels, as it seems that people generally agree that always requiring them in that scenario would make the experience of using enums worse rather than better. In fact, it seems that what's cited as a shortcoming in the original proposal ("labels in patterns aren't enforced") is precisely what we're trying to invent new sugar to duplicate.</div><div><br></div><div>Now, since we clearly want enum cases to be tuple-like in some respects (pattern matching) but function-like in other respects, is swinging from one extreme ("cases are tuples!") to the other ("cases are functions!") the right thing to do? Does it really make the language more "consistent"?</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 4:10 PM, Matthew Johnson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
> on Mon Feb 27 2017, Joe Groff <jgroff-AT-apple.com> wrote:<br>
><br>
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan <<a href="mailto:daniel@duan.org">daniel@duan.org</a>> wrote:<br>
>>><br>
>>> Before I start revising this proposal, there are a couple of open questions I’d like to discuss<br>
>> with the community and the core team.<br>
>>><br>
>>> The first question relates to the purpose of having a “internal”<br>
>>> argument name. There are applications of such names in GADT (if we<br>
>>> ever get there) and perhaps the case-as-subtype-of-the-enum stories<br>
>>> on the list right now. Out side of these scenarios, however, such<br>
>>> names has few chances to be used. The one I can come up with, which<br>
>>> is also the “open” part of the question, is this: we can use the<br>
>>> internal names in pattern matching, as opposed to using the<br>
>>> labels. This seems to align with the subtyping/GADT use cases. Is<br>
>>> this a desirable outcome?<br>
>><br>
>> Why would GADTs make internal argument names useful?<br>
><br>
> I'll probably never win this fight, but I'm trying to get people to use<br>
> “parameter name” and “argument label” as the preferred terms.<br>
<br>
</span>I like this terminology. I’ll start using it. Thanks for making an attempt to get everyone on the same page! :)<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
><br>
>> They seem completely useless to me. Their "internal"-ness is<br>
>> compromised if you try to hang semantics off of them—they shouldn't<br>
>> have any impact on use sites.<br>
>><br>
>>> The second open question is the syntax for “overloaded” cases. If we<br>
>>> decide to allow them, what should the patterns matching them look<br>
>>> like? I can think of one obvious-ish design where we make the<br>
>>> pattern look like the declaration and require types for<br>
>>> disambiguation. So the most verbose form of pattern would look<br>
>>> something like<br>
>>><br>
>>> ```<br>
>>> case let .baseName(label0 name0: Type0, label1 name1: Type1)<br>
>>> ```<br>
>><br>
>> By "overloaded", do you mean "same name different types", or "same<br>
>> base name, different argument names"?<br>
><br>
> When you write "argument name," do you mean parameter name or argument<br>
> label? This is an example of why I'd like us to settle on the other<br>
> terminology.<br>
><br>
>> I think we should have a consistent naming model where the latter is<br>
>> never considered overloading. As an affordance to make pattern<br>
>> matching more concise, it seems reasonable to me to maybe say that a<br>
>> binding pattern matches a label with the same name, so that `case<br>
>> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.<br>
><br>
> SGTM<br>
><br>
> --<br>
> -Dave<br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
</div></div></blockquote></div><br></div></div></div>