[swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation
Brent Royal-Gordon
brent at architechies.com
Sat Feb 18 05:49:24 CST 2017
> On Feb 17, 2017, at 7:26 PM, John McCall <rjmccall at 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#>):
…
}
…
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:):
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
More information about the swift-evolution
mailing list