[swift-evolution] [swift-evolution-announce] [Review] SE-0155: Normalize Enum Case Representation

[Daniel Duan]

Hi Brent,

> On Feb 18, 2017, at 3:49 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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#>):
> 		…
> 	}
> 	…
> 

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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution