On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan <dan...@duan.org> wrote: <snip>
> 4. > The proposal does not explore what happens when the proposed prohibition > on "mixing and matching" the proposed sugared and unsugared pattern > matching runs up against associated values that have a mix of labeled and > unlabeled parameters, and pattern matching user cases where the user does > not wish to bind all of the arguments. > > Given `case foo(a: Int, String, b: Int, String)`, the only sensible > interpretation of the rules for sugared syntax would allow the user to > choose any name for some but not all of the labels. If the user wishes to > bind only `b`, however, he or she will need to navigate a puzzling set of > rules that are not spelled out in the proposal: > > ``` > case foo(a: _, _, b: let b, _) > // this is definitely allowed > > case foo(a: _, _, b: let myVar, _) > // this is also definitely allowed > > // but... > case foo(_, _, b: let myVar, _) > // is this allowed, or must the user explicitly state and not bind `a`? > > // ...and with respect to the sugared version... > case foo(_, _, let b, _) > // is this allowed, or must the user explicitly state and not bind `a`? > ``` > > > Good point. To make up for this: `_` can substitute any sub pattern, which > is something that this proposal doesn’t change but definitely worth > spelling out. > 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() } ```
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution