> On Jan 19, 2017, at 2:29 PM, Joe Groff via swift-evolution > <[email protected]> wrote: > > >> On Jan 19, 2017, at 1:47 PM, Douglas Gregor via swift-evolution >> <[email protected]> wrote: >> >> This looks totally reasonable to me. A couple of comments: >> >> 1) Because this proposal is breaking the link between the associated value >> of an enum case and tuple types, I think it should spell out the rules that >> switch statements will use when matching an enum value against a a case with >> an associated value. Some kind of rules fell out of them being treated as >> tuple types, but they might not be what we want. > > I was about to bring up the same. Right now, an enum pattern works like > .<identifier> <tuple-pattern>, where the <tuple-pattern> then recursively > matches the payload tuple. In this model, it seems like we'd want to treat it > more like .<identifier>(<pattern>, <pattern>, ...). Similar to how we lost > "tuple splatting" to forward a bunch of arguments, we'd have to decide > whether we lose the ability to match all parts of the payload into a tuple. I > also don't think we currently enforce matching argument labels, so you can > match a `case foo(x: Int, y: Int)` with a `.foo(let q, let z)` or > `.foo(apples: let x, bananas: let y)` pattern. We should probably tighten > that up as part of this proposal as well.
This would be great to clean up. Sometime after this happens, we can reconsider nominal value matching (e.g. pattern match against fields within a struct). -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
