<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Apr 2, 2017, at 11:10 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sat, Apr 1, 2017 at 3:38 PM, Daniel Duan <span dir="ltr" class=""><<a href="mailto:daniel@duan.org" target="_blank" class="">daniel@duan.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class=""><snip></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" class=""><div class=""><div class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><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" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">4.</div><div class="">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.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">```</div><div class="">case foo(a: _, _, b: let b, _)</div><div class="">// this is definitely allowed</div><div class=""><br class=""></div><div class="">case foo(a: _, _, b: let myVar, _)</div><div class="">// this is also definitely allowed</div><div class=""><br class=""></div><div class="">// but...</div><div class=""><div class="">case foo(_, _, b: let myVar, _)</div><div class="">// is this allowed, or must the user explicitly state and not bind `a`?</div></div><div class=""><br class=""></div><div class="">// ...and with respect to the sugared version...</div><div class="">case foo(_, _, let b, _)</div><div class="">// is this allowed, or must the user explicitly state and not bind `a`?</div><div class="">```</div><div class=""><br class=""></div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">```</div><div class="">enum E {</div><div class=""> case foo(a: Int, b: Int, c: Int)</div><div class=""> case foo(a: String, c: String, e: String)</div><div class="">}</div><div class=""><br class=""></div><div class="">let e = /* instance of E */</div><div class=""><br class=""></div><div class="">switch e {</div><div class="">case foo(let a, _, _):</div><div class=""> // what type is `a` here?</div><div class=""> break</div><div class="">default:</div><div class=""> fatalError()</div><div class="">}</div><div class="">```</div></div><br class=""></div></div>
</div></blockquote></div><br class=""></div></div></body></html>