Hi Brent, > On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Feb 17, 2017, at 7:26 PM, John McCall <rjmcc...@apple.com> wrote: >> >> Proposal link: >> https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md >> >> • What is your evaluation of the proposal? > > I'm torn. Being able to handle the associated value as a tuple is very > convenient, but I also want the argument list features described here. In > practice, my own enums tend to end up using argument-like parameter labels, > which works better when constructing and pattern-matching, but worse when > extracting values. > > I think I'd like to ask for two changes. One is probably easy; the other is a > bit of a stretch. > > Easy: Cases should allow internal names for documentation and autocompletion. > > enum SQLError: Error { > … > case valueInvalid(_ underlying: Error, for key: SQLColumnKey, > in statement: SQLStatement) > … > } > … > throw SQLError.valueInvalid(error, for: key, in: statement) > … > switch sqlError { > case let .valueInvalid(<#underlying#>, for: <#key#>, in: <#statement#>): > … > } > … >
A very natural conclusion if one wants to use enum constructors like real functions. When I considered this, my reaction to it myself was that the internal name may not be very useful in a meaningful way. In pattern matching, for example, the variables declared in the pattern are the counterpart of internal name. Using the would-be external labels for associated values’ labels (hey, they are both called “labels”!). The last thing to note: we can add internal name later without making a breaking change. IMO this is worth considering if the community consider it valuable. > Stretch: There should be a way to extract the associated values during a > pattern match as a tuple. Sketch (with strawman syntax): > > // Different forms of the same case statement: > case let .valueInvalid(underlying, for: key, in: statement): > > case let params in . valueInvalid: > > case let params in . valueInvalid(_:for:in:): > > case let (underlying, key, statement) in . valueInvalid: > > case let (underlying, key, statement) in . valueInvalid(_:for:in:): Someone brought this up in the draft discussion as well. I prefer to delay this feature until we have a clearer story on “splats”. Since this is “splat” in reverse, the syntax could be related. > > Other than these things, I'm pretty happy with this proposal. I agree with > the ideas of treating the labels as part of the case name, making them more > usable as functions, and supporting default values. >> • Is the problem being addressed significant enough to warrant a change >> to Swift? > > Yes—the issues described in the "Motivation" section are pretty ugly. > >> • Does this proposal fit well with the feel and direction of Swift? > > Yes. > >> • If you have used other languages or libraries with a similar feature, >> how do you feel that this proposal compares to those? > > N/A. > >> • How much effort did you put into your review? A glance, a quick >> reading, or an in-depth study? > > Not really in-depth, but I did put some thought into it. > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > 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
