<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=""> struct Foo {</div><div class=""> static var bar = Foo()</div><div class=""> }</div><div class=""> extension Array {</div><div class=""> func map(foo: Foo) {}</div><div class=""> }</div><div class=""> [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. 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. The meaning of the dot-abbreviation could be defined in several ways. A static member returning the type is not one of them. In the context of the current map example the type returned by the dot-abbreviation expression would be ‘Element -> OtherType’. (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> var bar: Foo</div><div><br class=""></div><div> func bar() -> OtherType</div><div> func bar(s: String) -> OtherType</div><div><br class=""></div><div> // the property shadows the static function when accessed with Foo.bar syntax</div><div> // the same behavior would be exhibited in the shorthand if it applied to static members</div><div> static func bar(f: Foo) -> OtherType {}</div><div> static var bar: Foo -> 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) </div><div><br class=""></div><div><div>// </div><div>[Foo]().map(.bar) </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. Because curried syntax is getting dropped that would mean <b class="">only</b> unbound instance methods / properties / subscripts would be eligible. 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> for some developers, at least until they learn how it works. 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. I think it definitely deserves further consideration.</div><div><br class=""></div><div>Matthew</div></body></html>