<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 6:47 AM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 17, 2015, at 12:33 AM, 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">If you remove that overload your code will fail to compile. This is because the dot abbreviation is context sensitive. It only works when the type system knows the type the expression is expected to produce.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Of course :) And if the overload stays and your suggested syntax were added, it would be ambiguous and also fail to compile.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">This is not true. They would have different types and therefore would not be ambiguous.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">It's true in my example, but my example is an unlikely, type-ambiguous situation and is unlikely to occur in usage.</div></div></div></div></blockquote><div><br class=""></div><div>I finally managed to see the ambiguity in your example and now I feel foolish for not seeing it right away. Thanks for sticking with it until I understood your example correctly. :) I think it’s because I just kept thinking of the usual signature of map and maybe also because I was thinking more in terms of grammatical ambiguity.</div><div><br class=""></div><div>The overload in your example is possible but doesn’t really make any sense. Nonetheless, it does show that a certain kind of ambiguity is possible. </div><div><br class=""></div><div>The good news is that this is a kind of ambiguity that already exists in the language today. The compiler catches it and just requires you to resolve it manually when it arises. The same would be true if we adopt the instance method shorthand.</div><div><br class=""></div><div>struct Foo {<br class=""> static var ambiguous: Foo = Foo()<br class="">}<br class=""><br class="">struct Bar {<br class=""> static var ambiguous: Bar = Bar()<br class="">}<br class=""><br class="">func overloaded(foo: Foo) { }<br class="">func overloaded(bar: Bar) { }<br class=""><br class="">overloaded(.ambiguous) // compile error</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">But it’s not central to your position anyway since you are opposed on the grounds of potential for confusion rather than actual ambiguity. :) That is a fair and reasonable position with or without ambiguity.</div></div></div></div></blockquote></div><br class=""><div class="">I'm not opposed to the idea if it has broad applications and the type resolution is predictable. I think I'm probably doing a bad job of predicting.</div></div></div></blockquote><br class=""></div><div>Glad to hear you’re not completely opposed. I think it would have pretty broad applicability. It wouldn’t do anything you couldn’t achieve with a closure: { $0.method() }, but it would improve clarity and readability by removing syntactic noise. </div><div><br class=""></div><div>I’m going to start a new thread to bring more people into the discussion about this.</div><div><br class=""></div><div>Matthew</div><div class=""><br class=""></div></body></html>