> On Feb 19, 2017, at 11:49 AM, Matthew Johnson via swift-evolution > <[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] https://lists.swift.org/mailman/listinfo/swift-evolution
