<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><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="">I'm confused. Isn't a static member returning the type the _only_ way dot abbreviation works right right now? Please correct me with an example if I'm wrong.</div></div></div></div></div></blockquote><div><br class=""></div>I believe the dot abbreviation only works for enum cases right now. I suppose those can be viewed as static members in some sense but they really something different than that. If I am mistaken I would like to be corrected.<br class=""><div><br class=""></div><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="">I think I understand your examples. They just don't work right now and behave differently than dot abbreviation currently works.</div></div></div></div></div></blockquote><div><br class=""></div><div>Yes, they behave somewhat differently as they are an extension of the behavior to struct and class instance members.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div 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="">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).<br class=""></div><div class=""></div></div></blockquote><div class=""><br class=""></div><div class="">The shadowing you propose in your example attempts to resolve the ambiguity I was referring to.<br class=""></div></div></div></div></div></blockquote><div><br class=""></div><div>The shadowing is *current* behavior in the language. It is not something I propose.</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="">Let's take my earlier example. It would theoretically produce ambiguity if `Int` had a `bar` method. The resolver wouldn't have enough type information to resolve things. E.g.:</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=""> extension Int {</div><div class=""> func bar() -> String { return String(self) }</div><div class=""> }</div><div class=""> [1, 2, 3].map(.bar) // would this refer to `Foo.bar` or `Int.bar`?</div></div></div></div></div></div></blockquote><div><br class=""></div><div>This would not refer to either. It cannot refer to Foo.bar because Foo has nothing to do with the array you are mapping over. The syntax matching my example would be:</div><div><br class=""></div><div><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><div class="">[1, 2, 3].map(.bar())</div></div></div></div></div></div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Your example would seem to prefer `Int.bar`. This kind of complexity/gotcha/learning moment is something I'd rather avoid.</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 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></blockquote><div class=""><br class=""></div><div class="">Enum cases are static members (e.g., `enum Foo { case Bar }` allows you to reference the `Bar` case as `Foo.Bar`, or abbreviated as `.Bar` where type `Foo` is expected). This is what I was trying to communicate before. (The same static resolution lets you pass `.redColor()` where a `UIColor` is expected.) I'm just not sure co-opting dot abbreviation to also work with instance methods is worth the added complexity.</div></div></div></div></div></blockquote><br class=""></div><div>In the enum example here you cannot refer to .Bar in an arbitrary context. It must be known by context that you are referring to a case of Foo. It appears to me like your understanding of the existing dot abbreviation for enums is not quite correct and this misunderstanding is probably contributing to your misunderstanding and confusion regarding my examples.</div><div><br class=""></div><div>Matthew</div><br class=""></body></html>