<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 23, 2017, at 3:49 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On Jan 23, 2017, at 3:32 PM, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class="">This looks pretty good! It might be worth calling out explicitly that matching a payloaded case by name alone still works, e.g.:<div class=""><br class=""></div><div class="">enum Foo { case foo(Int), bar(x: Int) }</div><div class=""><br class=""></div><div class="">switch Foo.foo(0) {</div><div class="">case .foo:</div><div class=""> break</div><div class="">case .bar(x:):</div><div class=""> break</div><div class="">}</div></div></blockquote><div class=""><br class=""></div>In your example would 'bar(x:)' be required or would a naked 'bar' also be valid? I'm guessing it would not be valid which strikes me as slightly unfortunate. This would create some unpleasant verbosity in some places that isn't required today. (Incidentally, a nontrivial amount of this code would be in easily derivable "isSameCase" equivalence relations that compare the case used but not the associated values)</div></div></blockquote><div><br class=""></div>We're not terribly principled about this right now with non-pattern declaration references. You can still reference an unapplied function by its base name alone without its labels, if it's unambiguous:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>func foo(x: Int, y: Int) {}</div><div><br class=""></div><div>let foo_x_y: (Int, Int) -> () = foo</div></blockquote><div><br class=""></div><div>so it'd be consistent to continue to allow the same in pattern references.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><div class=""><br class=""></div><div class="">Another question - if labels become part of the case name does that mean we can "overload" the base name?</div><div class=""><br class=""></div><div class="">enum Foo {</div><div class=""> case bar(x: Int)</div><div class=""> case bar(y: Int)</div><div class="">}</div><div class=""><br class=""></div><div class="">The example is intentionally problematic because I'm not sure this would be a good idea, but more realistic examples may be possible with cases more meaningfully distinguished by associated value labels. </div><div class=""><br class=""></div><div class="">This is an idea that naturally follows with a move to a more function-like model of enum cases with labels being part of the name so it's worth discussing whether or not it should be allowed.</div></div></div></div></blockquote><br class=""></div><div>Yeah, if labels really are part of the decl name then this isn't an "overload" at all, so we should allow it.</div><div><br class=""></div><div>-Joe</div></body></html>