> On Feb 25, 2017, at 6:13 AM, Matthew Johnson <[email protected]> wrote: > > > > Sent from my iPad > > On Feb 24, 2017, at 11:26 PM, Daniel Duan via swift-evolution > <[email protected] <mailto:[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? > > This is what I suggested. I think of it like this: the case includes a > static factory method that produces values. We obviously want the external > label here. The pattern is like matching a labeled tuple. When we think of > the cases as a labeled tuple (or synthesized struct in the case-as-subtype > world) it is clear (to me at least) that we want to use the internal name. > To avoid the noise, I suggest allowing patterns to elide the label if they > bind to an identical name, which is often what they will do. > >> >> 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) >> ``` > > We don't need new syntax for this. Cast patterns in the associated value > slots should work just fine: > > case let .baseName(name0 as Type0, name1 as Type1) > > Here, `name0` and `name1` are the internal names of the pattern. If the > pattern had different internal names the label must be used: > > case let .baseName(internalName1: name0 as Type0, internalName2: name1 as > Type1) > > Note: the syntactic sugar of eliding the label should also be allowed in > cases that don't don't distinguish the internal and external names.
Nice! > >> >> Even in this design, there are the choice of forcing name0/name1 to match >> the “internal” name in declaration and letting users choose whatever they >> want. There maybe way elegant syntax that I haven’t thought of. Since my >> experience with languages with pattern matching syntax is pretty much >> limited to SML and Haskell, I must admit my inadequacy here. Any help is >> appreciated here! >> >> >>> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> My apologies for misunderstanding. >>>> >>>> Would it be better to add the anonymous case feature in a separate >>>> proposal? It stands alone as a new addition to enum. The intent for this >>>> proposal is bringing enum's syntax closure to other part of Swift. >>> >>> The core team met and talked about SE-0155 today, even though we're not >>> quite done with the review period, and here's where we stand. >>> >>> SE-0155 is being returned for revision. Consensus appears to be strongly >>> in favor of requiring argument labels (if provided) to be enforced on >>> "call" sites. However, the core team feels that the proposal needs >>> revision in the following ways: >>> - Are internal argument names syntactically allowed in a case declaration? >>> - Can cases with the same base name be overloaded by argument label? If >>> so, is a pattern match using just the bare name ambiguous or does it match >>> both cases? >>> - Can cases with the same name (using the same rule as above) be >>> overloaded by argument type? If so, how are they disambiguated in pattern >>> matches? >>> - Do pattern matches require argument labels to be given along with value >>> patterns, e.g. "case .valid(value: let value)", or is there some way to >>> shorten this? If the latter, what are the rules for that? >>> - Are you proposing anonymous cases, and if so, what are the language >>> rules for them? >>> - The proposal makes a claim about layout efficiency; please either >>> discuss this claim or remove it. >>> >>> John. >>> >>>> >>>> Daniel Duan >>>> Sent from my iPhone >>>> >>>> On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> I had not intended for _ to be an ordinary identifier, but as a way of >>>>> spelling the empty case name. Ambiguous cases, not distinguished by >>>>> either full name or payload type, would be errors. How to construct >>>>> anonymous cases? I guess it would be MyEnum(expression) >>>>> >>>>> Sent from my moss-covered three-handled family gradunza >>>>> >>>>> On Feb 19, 2017, at 2:52 PM, Daniel Duan <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>>> >>>>>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution >>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >>>>>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>> I'm on vacation and don't have time for a full review right now, but I >>>>>>>> am concerned that wild this proposal would make enums more general and >>>>>>>> uniform with the rest of the language , they also would become much >>>>>>>> more awkward for common use cases. I have recently been very pleased >>>>>>>> that I didn't have to supply labels in switch statements where the >>>>>>>> label name would simply have matched the name of the variable to be >>>>>>>> bound. This looks needlessly verbose: >>>>>>>> >>>>>>>> case .valid(value: let value, resumptionPoint: let resumptionPoint): >>>>>>>> >>>>>>>> I cannot imagine a real life use case where one would have labels in >>>>>>>> the case and desire to bind associated values to variables having >>>>>>>> different names than the labels. >>>>>>> >>>>>>> I agree with this, but I think it’s an issue we can solve (perhaps as >>>>>>> an amendment to this proposal). >>>>>>> >>>>>>> First, I think Brent’s idea of introducing an argument label that can >>>>>>> be distinct from the “property” name of the case is a good one. I >>>>>>> think we should do this. It takes the parallel with function >>>>>>> signatures even further. >>>>>>> >>>>>>> Second, we should allow the “property” name to be `_`. This would mean >>>>>>> no label can be used when matching: >>>>>>> >>>>>>> case valid(value _: ValueType, resumptionPoint _: PointType) >>>>>>> >>>>>>> Third, I think we should also allow suers to elide the label if they >>>>>>> either discard the value with `_` or bind a name that is identical to >>>>>>> the label, so we might have: >>>>>>> >>>>>>> // declaration: >>>>>>> case valid(externalCasConstructorLabel value: ValueType, >>>>>>> externalCaseConstructorLabel resumptionPoint: PointType) >>>>>>> >>>>>>> // match ok: >>>>>>> case .valid(let value, let resumptionPoint): >>>>>>> >>>>>>> // error, names do not match: >>>>>>> case .valid(let foo, let bar): >>>>>>> >>>>>>> // ok, label is used: >>>>>>> case .valid(value: let foo, resumptionPoint: let bar): >>>>>>> >>>>>>> This follows the behavior of function signatures very closely. The >>>>>>> external label is used to provide context for the argument at the call >>>>>>> site (of the case constructor). The internal name is used to bind a >>>>>>> name to the value that is used by code that works with the value. >>>>>>> >>>>>>> The only exception here is that because the usage site is distant from >>>>>>> the case declaration it may wish to use a different name. We allow >>>>>>> that, but only if the “internal name” is also used in the pattern. >>>>>>> This preserves the ability of a reader of the code to see the name / >>>>>>> meaning of the associated value as it was declared by the enum in >>>>>>> addition to the name that might make more sense for use in the local >>>>>>> context. >>>>>>> >>>>>>>> >>>>>>>> Secondly, I can't imagine a case where one would want to use the same >>>>>>>> case basename and different labels. The very common use case where the >>>>>>>> types of associated values completely distinguish the case and one >>>>>>>> would rather not have to supply a case name at all is completely >>>>>>>> unaddressed. If my quick read is not mistaken, this proposal makes it >>>>>>>> legal for cases to have different complete names (including base name >>>>>>>> and labels), but doesn't make it legal to have the same full name >>>>>>>> (which I would love to be "_" or missing in some cases) with different >>>>>>>> associated value types. If we were truly following the precedent set >>>>>>>> by function signatures, wouldn't that be possible too? >>>>>>> >>>>>>> +1. I think this makes a lot of sense. It completes the parallel of >>>>>>> cases with overloaded functions. >>>>>>> >>>>>>> I think anonymous cases are a really good idea. I discuss those quite >>>>>>> a bit in the value subtyping manifesto I shared last week (I’d love to >>>>>>> hear your thoughts on it if / when you have time to take a look). >>>>>>> >>>>>>> How would you propose that values of anonymous cases be constructed and >>>>>>> matched? My solution is to allow them to be constructed by implicit >>>>>>> conversion from the associated value type to the enum type and matched >>>>>>> by a cast pattern. Is that what you have in mind? I would *really* >>>>>>> love to see this someday... >>>>>> >>>>>> I can’t speak for Dave obviously. But I think he was merely proposing >>>>>> “overloaded” form of enum options, in which multiple options may share >>>>>> the compound name but with differently associated types. The name “_” >>>>>> would just be a normal identifier in such scenario. So it would also be >>>>>> the contractor’s function name. >>>>>> >>>>>>>> >>>>>>>> Sent from my moss-covered three-handled family gradunza >>>>>>>> >>>>>>>> On Feb 17, 2017, at 5:26 PM, John McCall <[email protected] >>>>>>>> <mailto:[email protected]>> wrote: >>>>>>>> >>>>>>>>> Hello Swift community, >>>>>>>>> >>>>>>>>> The review of "SE-0155: Normalize Enum Case Representation" begins >>>>>>>>> now and runs through next Friday, February 26th. The proposal is >>>>>>>>> available here: >>>>>>>>> >>>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md >>>>>>>>> >>>>>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md> >>>>>>>>> >>>>>>>>> Reviews are an important part of the Swift evolution process. All >>>>>>>>> reviews should be sent to the swift-evolution mailing list at >>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>>>> or, if you would like to keep your feedback private, directly to the >>>>>>>>> review manager. When replying, please try to keep the proposal link >>>>>>>>> at the top of the message: >>>>>>>>> >>>>>>>>> Proposal link: >>>>>>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md >>>>>>>>> >>>>>>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md> >>>>>>>>> >>>>>>>>> Reply text >>>>>>>>> >>>>>>>>> Other replies >>>>>>>>> >>>>>>>>> What goes into a review? >>>>>>>>> >>>>>>>>> The goal of the review process is to improve the proposal under >>>>>>>>> review through constructive criticism and, eventually, determine the >>>>>>>>> direction of Swift. When writing your review, here are some questions >>>>>>>>> you might want to answer in your review: >>>>>>>>> >>>>>>>>> • What is your evaluation of the proposal? >>>>>>>>> • Is the problem being addressed significant enough to warrant >>>>>>>>> a change to Swift? >>>>>>>>> • Does this proposal fit well with the feel and direction of >>>>>>>>> Swift? >>>>>>>>> • If you have used other languages or libraries with a similar >>>>>>>>> feature, how do you feel that this proposal compares to those? >>>>>>>>> • How much effort did you put into your review? A glance, a >>>>>>>>> quick reading, or an in-depth study? >>>>>>>>> >>>>>>>>> More information about the Swift evolution process is available at >>>>>>>>> https://github.com/apple/swift-evolution/blob/master/process.md >>>>>>>>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> >>>>>>>>> John McCall >>>>>>>>> Review Manager >>>>>>>>> _______________________________________________ >>>>>>>>> swift-evolution-announce mailing list >>>>>>>>> [email protected] >>>>>>>>> <mailto:[email protected]> >>>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution-announce> >>>>>>>> _______________________________________________ >>>>>>>> swift-evolution mailing list >>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] <mailto:[email protected]> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
