> On Feb 17, 2017, at 7:26 PM, John McCall <[email protected]> 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

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to