<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="">Great suggestion. Done.<br class=""><div><blockquote type="cite" class=""><div class="">On Jan 24, 2017, at 5:07 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Ok, sounds logical. Might be worth adding that info to the proposal to make it clear how ambiguity plays out.<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 24 Jan 2017, at 13:27, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">I would imagine it would be logical to have it work just like it does now with functions. If case bar is distinct, then that should still work, but if bar is "overloaded," then case bar should be invalid for ambiguity. Seems fine to me, shouldn't break any existing code and therefore we don't lose anything.<br class=""><br class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Jan 24, 2017 at 01:13 David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg">On 24 Jan 2017, at 00:52, Joe Groff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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 class="gmail_msg"><br class="gmail_msg"></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="gmail_msg"><div class="gmail_msg">func foo(x: Int, y: Int) {}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">let foo_x_y: (Int, Int) -> () = foo</div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">so it'd be consistent to continue to allow the same in pattern references.</div></div></blockquote><br class="gmail_msg"></div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">WRT ambiguity, do we loose the ability to pattern match on the naked case name when two cases share the same base name?</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">enum Foo {</div><div class="gmail_msg"> case bar(a: Int)</div><div class="gmail_msg"> case bar(b: String)</div><div class="gmail_msg">}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">switch aFoo {</div><div class="gmail_msg"> case .bar: // matches both cases</div><div class="gmail_msg"> break</div><div class="gmail_msg">}</div></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote></div><br class=""></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>