> On Feb 27, 2017, at 4:07 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Mon Feb 27 2017, Joe Groff <jgroff-AT-apple.com> wrote: > >>> On Feb 24, 2017, at 9:26 PM, Daniel Duan <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
