<div dir="ltr">On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan <span dir="ltr">&lt;<a href="mailto:daniel@duan.org" target="_blank">daniel@duan.org</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>&lt;snip&gt;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><span class=""><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>4.</div><div>The proposal does not explore what happens when the proposed prohibition on &quot;mixing and matching&quot; 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.</div><div><br></div><div>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:</div><div><br></div><div>```</div><div>case foo(a: _, _, b: let b, _)</div><div>// this is definitely allowed</div><div><br></div><div>case foo(a: _, _, b: let myVar, _)</div><div>// this is also definitely allowed</div><div><br></div><div>// but...</div><div><div>case foo(_, _, b: let myVar, _)</div><div>// is this allowed, or must the user explicitly state and not bind `a`?</div></div><div><br></div><div>// ...and with respect to the sugared version...</div><div>case foo(_, _, let b, _)</div><div>// is this allowed, or must the user explicitly state and not bind `a`?</div><div>```</div><div><br></div></div></div></div></div></blockquote><div><br></div></span><div>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.  </div></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>```</div><div>enum E {</div><div>  case foo(a: Int, b: Int, c: Int)</div><div>  case foo(a: String, c: String, e: String)</div><div>}</div><div><br></div><div>let e = /* instance of E */</div><div><br></div><div>switch e {</div><div>case foo(let a, _, _):</div><div>  // what type is `a` here?</div><div>  break</div><div>default:</div><div>  fatalError()</div><div>}</div><div>```</div></div><br></div></div>