<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 <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> 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. This is pretty interesting. Is this covered in any documentation? I haven’t seen anything about it nor any code that uses this until now. It would be useful with factory methods. 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. 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. I tested it in an app rather than a playground (moving the print line into main).</div><div class=""><br class=""></div>struct 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=""> //static var bar: Foo -> String = { _ in return "var" }<br class=""> static func bar(f: Foo) -> String { return "func" }<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())) </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> struct Foo {<br class=""> //static var bar: String = "var"<br class=""> static func bar() -> String { return "func" }<br class=""> }<br class=""> // prints "func" and won't compile if you uncomment the var<br class=""> print(Foo.bar(Foo())) <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. 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. 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. This is because the dot abbreviation is context sensitive. 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. As you note, the type of the static property or method must always be Self, which is never going to be a function type. This means that it is never going to have the same type as an unbound instance method (that its non-self arguments bound). </div><div class=""><br class=""></div><div class="">Because of this the two shorthand notations will never be applicable in the same type context. I can see how the similarity could be confusing but it is not ambiguous. 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>