> On Feb 22, 2017, at 11:27 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Feb 21, 2017, at 4:43 AM, Daniel Duan via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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.
Does this mean pattern matches as well? That adds a lot of verbosity for no gain. Russ > 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 >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <dan...@duan.org >>> <mailto:dan...@duan.org>> wrote: >>> >>>> >>>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>>> >>>>>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <rjmcc...@apple.com >>>>>> <mailto:rjmcc...@apple.com>> 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 >>>>>>> swift-evolution-annou...@swift.org >>>>>>> <mailto:swift-evolution-annou...@swift.org> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution-announce> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
