<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">My observations of this discussion so far:</div><div class=""><br class=""></div><div class="">First of all, I think there’s no inherent conflict in "making enum constructors look like function" and “making patterns look like tuple”. These can and should be considered orthogonal aspects of enum in the language.</div><div class=""><br class=""></div><div class="">At the risk of over simplifying, I’d like to pick a few conflicting design choices that came up and put them in two columns.</div><div class=""><br class=""></div><div class="">Column A argues for simplicity of the language, better teachability and perhaps more consistency. In this column we have:</div><div class=""><br class=""></div><div class="">1. Enum constructors: Be like functions, have parameter names as well as argument labels.</div><div class="">2. Argument labels in patterns: Require argument label, making patterns look more like the declaration</div><div class="">3. Binding name in patterns: Require matching with argument labels (or maybe parameter names)</div><div class=""><br class=""></div><div class="">Column B argues for better ergonomics and authoring experience, even improved readability in same cases:</div><div class=""><br class=""></div><div class=""><div class="">1. Enum constructors: Do not introduce parameter names (until we have concrete uses for them in the future)</div><div class="">2. Argument labels in patterns: Allow skipping of all argument labels, matching by position.</div><div class="">3. Binding name in patterns: Allow arbitrary names (or only allow such bindings when labels are supplied)</div></div><div class=""><br class=""></div><div class="">Here’s they are again for those with GUI/Web email clients:</div><div class=""><img apple-inline="yes" id="CAE6705A-57EA-4D96-93AE-D85729607596" width="657" height="361" src="cid:88554068-89CD-427E-9B30-18BF3A35CAEE" class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">There are things that doesn’t fit (overloading cases by type, for example, makes the constructors more consistent with functions, but it’s unclear whether it makes the language simpler or more complex).</div><div class=""><br class=""></div><div class="">Both the first revision of this proposal and the next are “a little from column A and a little from column B”. But neither column is *wrong* really. I’m confident that we are *not* doomed!</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On Feb 27, 2017, at 7:17 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Having watched this conversation from the sidelines, I just wanted to chime in from a more distant view:<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- 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 class=""><br class=""></div><div class="">- 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 class=""><br class=""></div><div class="">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 class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Feb 27, 2017 at 4:10 PM, Matthew Johnson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><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 class="">
> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
><br class="">
><br class="">
> on Mon Feb 27 2017, Joe Groff <<a href="http://jgroff-AT-apple.com" class="">jgroff-AT-apple.com</a>> wrote:<br class="">
><br class="">
>>> On Feb 24, 2017, at 9:26 PM, Daniel Duan <<a href="mailto:daniel@duan.org" class="">daniel@duan.org</a>> wrote:<br class="">
>>><br class="">
>>> Before I start revising this proposal, there are a couple of open questions I’d like to discuss<br class="">
>> with the community and the core team.<br class="">
>>><br class="">
>>> The first question relates to the purpose of having a “internal”<br class="">
>>> argument name. There are applications of such names in GADT (if we<br class="">
>>> ever get there) and perhaps the case-as-subtype-of-the-enum stories<br class="">
>>> on the list right now. Out side of these scenarios, however, such<br class="">
>>> names has few chances to be used. The one I can come up with, which<br class="">
>>> is also the “open” part of the question, is this: we can use the<br class="">
>>> internal names in pattern matching, as opposed to using the<br class="">
>>> labels. This seems to align with the subtyping/GADT use cases. Is<br class="">
>>> this a desirable outcome?<br class="">
>><br class="">
>> Why would GADTs make internal argument names useful?<br class="">
><br class="">
> I'll probably never win this fight, but I'm trying to get people to use<br class="">
> “parameter name” and “argument label” as the preferred terms.<br class="">
<br class="">
</span>I like this terminology. I’ll start using it. Thanks for making an attempt to get everyone on the same page! :)<br class="">
<div class="gmail-HOEnZb"><div class="gmail-h5"><br class="">
><br class="">
>> They seem completely useless to me. Their "internal"-ness is<br class="">
>> compromised if you try to hang semantics off of them—they shouldn't<br class="">
>> have any impact on use sites.<br class="">
>><br class="">
>>> The second open question is the syntax for “overloaded” cases. If we<br class="">
>>> decide to allow them, what should the patterns matching them look<br class="">
>>> like? I can think of one obvious-ish design where we make the<br class="">
>>> pattern look like the declaration and require types for<br class="">
>>> disambiguation. So the most verbose form of pattern would look<br class="">
>>> something like<br class="">
>>><br class="">
>>> ```<br class="">
>>> case let .baseName(label0 name0: Type0, label1 name1: Type1)<br class="">
>>> ```<br class="">
>><br class="">
>> By "overloaded", do you mean "same name different types", or "same<br class="">
>> base name, different argument names"?<br class="">
><br class="">
> When you write "argument name," do you mean parameter name or argument<br class="">
> label? This is an example of why I'd like us to settle on the other<br class="">
> terminology.<br class="">
><br class="">
>> I think we should have a consistent naming model where the latter is<br class="">
>> never considered overloading. As an affordance to make pattern<br class="">
>> matching more concise, it seems reasonable to me to maybe say that a<br class="">
>> binding pattern matches a label with the same name, so that `case<br class="">
>> .foo(let bar, let bas)` can match `.foo(bar:bas:)`.<br class="">
><br class="">
> SGTM<br class="">
><br class="">
> --<br class="">
> -Dave<br class="">
> ______________________________<wbr class="">_________________<br class="">
> swift-evolution mailing list<br class="">
> <a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class="">
______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
</div></div></blockquote></div><br class=""></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>