> On Feb 24, 2017, at 9:26 PM, Daniel Duan <dan...@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? 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"? 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:)`. -Joe _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
