Sent from my iPad
> On Feb 19, 2017, at 6: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. So values would be constructed like MyEnum._(42) and matched like ._(let i as Int). Is that what you're thinking? I suppose that would be a reasonable step to take for now. Making MyEnum a subtype of the case types still seems like a more elegant long term goal. > >>> >>> 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
