<div dir="ltr">On Wed, Dec 16, 2015 at 1:13 PM, Matthew Johnson <span dir="ltr">&lt;<a href="mailto:matthew@anandabits.com" target="_blank">matthew@anandabits.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><br><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"><span class=""><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 -&gt; OtherType’.  (Element being the type contained in the array, which would be Self in the context of that type)<br></div></span></div></blockquote><div><br></div><div>I&#39;m confused. Isn&#39;t a static member returning the type the _only_ way dot abbreviation works right right now? Please correct me with an example if I&#39;m wrong.</div><div><br></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"><span class=""><div></div></span><div>Here are some examples:</div></div></blockquote><div><br></div><div>I think I understand your examples. They just don&#39;t work right now and behave differently than dot abbreviation currently works.</div><div> </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"><div>It is possible this syntax would be <b>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></div><div></div></div></blockquote><div><br></div><div>The shadowing you propose in your example attempts to resolve the ambiguity I was referring to.<br></div><div><br></div><div>Let&#39;s take my earlier example. It would theoretically produce ambiguity if `Int` had a `bar` method. The resolver wouldn&#39;t have enough type information to resolve things. E.g.:</div><div><br></div><div><div>    struct Foo {</div><div>        static var bar = Foo()</div><div>    }</div><div>    extension Array {</div><div>        func map(foo: Foo) {}</div><div>    }</div><div>    extension Int {</div><div>        func bar() -&gt; String { return String(self) }</div><div>    }</div><div>    [1, 2, 3].map(.bar) // would this refer to `Foo.bar` or `Int.bar`?</div></div><div><br></div><div>Your example would seem to prefer `Int.bar`. This kind of complexity/gotcha/learning moment is something I&#39;d rather avoid.</div><div><br></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"><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></blockquote><div><br></div><div>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&#39;m just not sure co-opting dot abbreviation to also work with instance methods is worth the added complexity.</div><div><br></div><div>Hope I&#39;m being clearer this time around, and let me know if I&#39;m still not making sense or if I&#39;m missing anything.</div></div><br></div><div class="gmail_extra">Stephen</div></div>