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

[Brent Royal-Gordon]

> On Apr 2, 2017, at 11:17 PM, Daniel Duan via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Apr 2, 2017, at 11:10 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> This rule cannot hold. You cannot have the shorthand syntax you propose, disallow mixing of shorthand syntax and the longer form, *and* allow `_` to substitute for any pattern without a label.
>> 
>> ```
>> enum E {
>>   case foo(a: Int, b: Int, c: Int)
>>   case foo(a: String, c: String, e: String)
>> }
>> 
>> let e = /* instance of E */
>> 
>> switch e {
>> case foo(let a, _, _):
>>   // what type is `a` here?
>>   break
>> default:
>>   fatalError()
>> }
>> ```

> 

> That seems like straight up ambiguity with or without restriction on the label though? This kind of usability problem should and is discouraged by the proposed solution.

Let's make it a little more reasonable:

	enum Color {
		case color(red: CGFloat, green: CGFloat, blue: CGFloat, alpha: CGFloat)
		case color(hue: CGFloat, saturation: CGFloat, value: CGFloat, alpha: CGFloat)
	}

	let c: Color = …
	
	switch c {
	case .color(_, _, _, let alpha):
		…
	}

Interestingly, in this example it would probably be appropriate to match both cases. I wonder if that's true in the general case.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170402/3a3b45d1/attachment.html>