<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="">On Dec 16, 2015, at 11:28 PM, Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; wrote:</div><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=""><br class=""></div><div class="">I stand corrected. &nbsp;This is pretty interesting. &nbsp;Is this covered in any documentation? &nbsp;I haven’t seen anything about it nor any code that uses this until now. &nbsp;It would be useful with factory methods. &nbsp;I appreciate your calling this to my attention!</div></div></div></blockquote><div><br class=""></div><div>I think it's described, but obviously not clearly enough. Might be worth opening a bug requesting better documentation around the behavior.</div><br 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=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><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 class="" style="word-wrap: break-word;"><div class=""><div class="">The shadowing is *current* behavior in the language.&nbsp; It is not something I propose.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Is this true? Can you provide a full example that works in the playground and demonstrates this? The hypothetical you paste already has certain ambiguous issues (e.g. `var foo` and `func foo()` cannot compile together because of redefinition).</div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Here is an example. &nbsp;I tested it in an app rather than a playground (moving the print line into main).</div><div class=""><br class=""></div>struct&nbsp;Foo {</div><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="">&nbsp; &nbsp;&nbsp;//static var bar: Foo -&gt; String = { _ in return "var" }<br class="">&nbsp; &nbsp;&nbsp;static&nbsp;func&nbsp;bar(f:&nbsp;Foo) -&gt;&nbsp;String&nbsp;{&nbsp;return&nbsp;"func"&nbsp;}<br class="">}</div><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="">// prints “func”, but will compile and print “bar” if you uncomment the var<br class="">print(Foo.bar(Foo()))&nbsp;</div></div></blockquote><div><br class=""></div><div>Ah, yeah, the fact that there are arguments disambiguates (which is interesting in itself). If you make a variable and then a function without arguments, per your earlier example, it won’t compile:</div><div><br class=""></div><div>&nbsp; &nbsp; struct Foo {<br class="">&nbsp; &nbsp; &nbsp; &nbsp; //static var bar: String = "var"<br class="">&nbsp; &nbsp; &nbsp; &nbsp; static func bar() -&gt; String { return "func" }<br class="">&nbsp; &nbsp; }<br class="">&nbsp; &nbsp; // prints "func" and won't compile if you uncomment the var<br class="">&nbsp; &nbsp; print(Foo.bar(Foo()))&nbsp;<br class=""></div><br 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=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><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 class="" style="word-wrap: break-word;"><div class=""><div class="">This would not refer to either.&nbsp; It cannot refer to Foo.bar because Foo has nothing to do with the array you are mapping over.</div></div></div></blockquote><div class=""><br class=""></div><div class=""><div class="">The example I give works in the playground. Try it! :)</div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">You are right here as well. &nbsp;I didn’t read closely enough and didn’t notice the overload of map you added to Array.</div><div class=""><br class=""></div><div class="">If you remove that overload your code will fail to compile. &nbsp;This is because the dot abbreviation is context sensitive. &nbsp;It only works when the type system knows the type the expression is expected to produce.</div></div></div></blockquote><div><br class=""></div><div>Of course :) And if the overload stays and your suggested syntax were added, it would be ambiguous and also fail to compile.</div><br 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="">Because of this context sensitivity no ambiguity would arise from the example you provided. &nbsp;As you note, the type of the static property or method must always be Self, which is never going to be a function type. &nbsp;This means that it is never going to have the same type as an unbound instance method (that its non-self arguments bound). &nbsp;</div><div class=""><br class=""></div><div class="">Because of this the two shorthand notations will never be applicable in the same type context. &nbsp;I can see how the similarity could be confusing but it is not ambiguous. &nbsp;The potential confusion might even be enough to avoid introducing it into the language, but I’m not sure about that.</div></div></div></blockquote><div><br class=""></div>This was my exact point earlier. It's unlikely to be ambiguous (because context _generally_ disambiguates), but in the examples I give, they certainly are ambiguous (and thus can be).</div><div><br class=""></div><div>My general stance remains that, while an interesting idea, adding a second behavior around dot abbreviation causes more confusion than it's worth (especially given that the behavior is not well understood—this thread being an example), and that {$0.whatever} is not a big burden over (.whatever).</div><div><br class=""></div><div>Stephen<br class=""></div><div><br class=""></div></body></html>