I prefer patterns and matching cases have a many-to-one relation. Keep in mind, our goal is to make match site more readable/teachable. I’d venture to say that given the definition of “Color”, this pattern is really unreadable. So is this kind of attempt to disambiguate, if we allow mixture of long/short forms:
case .color(hue: _, _, let alpha): // yuck > On Apr 2, 2017, at 11:46 PM, Brent Royal-Gordon <[email protected]> > wrote: > >> On Apr 2, 2017, at 11:17 PM, Daniel Duan via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> On Apr 2, 2017, at 11:10 PM, Xiaodi Wu <[email protected] >>> <mailto:[email protected]>> 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
