> On Feb 27, 2017, at 1:39 PM, Daniel Duan <[email protected]> wrote: >> On Feb 27, 2017, at 10:00 AM, Joe Groff <[email protected]> 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? 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. > > Interesting. > > I was reaching for any possible use cases there. The theory is these names > would be how one refers to a "property" of the case in, say, extension > methods for the case. > > But yeah, I considered this internal name thing during first draft and > decided that they weren't necessary 🤷♀️
I think the strongest argument here is that internal names already have an accepted meaning, which is just that they name the argument variables in the following code. Today, cases don't have any following code, but if/when we add that in SE-9999, people will obviously expect internal names to name those argument variables. Even if the SE-9999 proposers decide that, actually, using internal names for case arguments isn't a good idea, they will still need to do something about that natural user expectation, and they shouldn't be limited by us having carelessly given internal names some random other meaning way back in SE-0155. John. >> >>> 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"? I think we should have a consistent naming >> model where the latter is never considered overloading. > > Same name different type is what "overloading" was meant here. "Same base > name" is already in the first revision and wouldn't fit in this "open > question" discussion. > >> 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:)`. > > Good idea. > >> -Joe > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
