<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=""><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">Sorry, I meant ambiguous via extension (on a sequence type). Super contrived example:</div><div class=""><br class=""></div><div class=""><div class="">&nbsp; &nbsp; struct Foo {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; static var bar = Foo()</div><div class="">&nbsp; &nbsp; }</div><div class="">&nbsp; &nbsp; extension Array {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; func map(foo: Foo) {}</div><div class="">&nbsp; &nbsp; }</div><div class="">&nbsp; &nbsp; [1, 2, 3].map(.bar)</div></div><div class=""><br class=""></div><div class="">I doubt there would be much ambiguity in practice, as disambiguation would come naturally at the call site.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">There would not be an entirely new meaning for the . shorthand.&nbsp; It would be an extrapolation of the shorthand for enum cases.<br class=""></div></div></blockquote><div class=""><br class=""></div><div class="">I merely meant that dot-abbreviation now specifically resolves to a static member that returns the type. The dot-abbreviation in your examples is a different behavior and adds a bit of complexity to learning Swift.</div></div></div></div></div></blockquote><br class=""></div><div>This is still not correct for a couple of reasons. &nbsp;The meaning of the dot-abbreviation could be defined in several ways. &nbsp;A static member returning the type is not one of them. &nbsp;In the context of the current map example the type returned by the dot-abbreviation expression would be ‘Element -&gt; OtherType’. &nbsp;(Element being the type contained in the array, which would be Self in the context of that type)</div><div><br class=""></div><div>Here are some examples:</div><div><br class=""></div><div>struct Foo {</div><div>&nbsp; &nbsp; var bar: Foo</div><div><br class=""></div><div>&nbsp; &nbsp; func bar() -&gt; OtherType</div><div>&nbsp; &nbsp; func bar(s: String) -&gt; OtherType</div><div><br class=""></div><div>&nbsp; &nbsp; // the property shadows the static function when accessed with Foo.bar syntax</div><div>&nbsp; &nbsp; // the same behavior would be exhibited in the shorthand if it applied to static members</div><div>&nbsp; &nbsp; static func bar(f: Foo) -&gt; OtherType {}</div><div>&nbsp; &nbsp; static var bar: Foo -&gt; OtherType = { _ in OtherType() }</div><div>}</div><div><br class=""></div><div>[Foo]().map(.bar()) // instance method</div><div>[Foo]().map(.bar(“hello")) // instance method</div><div>[Foo]().map(.bar#get) // instance property</div><div><br class=""></div><div>// this would reference a static property or static function if that is allowed</div><div>// however if we define the dot-abbreviation to access only unbound instance members</div><div>// this could be a shorthand for .bar#get as it would be the only unbound instance member with the correct type</div><div>[Foo]().map(.bar)&nbsp;</div><div><br class=""></div><div><div>//&nbsp;</div><div>[Foo]().map(.bar)&nbsp;</div></div><div><br class=""></div><div>If we do add a dot-abbreviation like this it would probably make sense to define it such that it <b class="">only</b> applies to curried functions where the first argument is of the type required in the context. &nbsp;Because curried syntax is getting dropped that would mean <b class="">only</b>&nbsp;unbound instance methods / properties / subscripts would be eligible. &nbsp;Because the dot-abbreviation would be defined as an unbound reference we probably don’t need the special syntax for getters and subscripts.</div><div><br class=""></div><div>It is possible this syntax would be <b class="">confusing</b>&nbsp;for some developers, at least until they learn how it works. &nbsp;But I don’t think we’ve seen any examples of ambiguity yet (of course there may be some we just haven’t discussed yet).</div><div><br class=""></div><div>There is precedent for dot-abrreviation in the language already related to enums and this definitely improves clarity and readability. &nbsp;I think it definitely deserves further consideration.</div><div><br class=""></div><div>Matthew</div></body></html>