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.
Daniel Duan Sent from my iPhone > On Feb 21, 2017, at 1:15 AM, Dave Abrahams via swift-evolution > <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> wrote: >> >> >>>> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>> On Feb 18, 2017, at 10:49 PM, Dave Abrahams via swift-evolution >>>> <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> 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 >>>>> >>>>> 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 >>>>> 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 >>>>> >>>>> 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 >>>>> >>>>> Thank you, >>>>> >>>>> John McCall >>>>> Review Manager >>>>> _______________________________________________ >>>>> swift-evolution-announce mailing list >>>>> swift-evolution-annou...@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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
