<div dir="ltr">Is a solution to this actually making the leading dot mean enum lookup, full stop and allowing `Self.foo`? The case that that doesn&#39;t cover is static members on a type other than `Self`. I use it to great effect for standard instances of types, so I would appreciate *some* facility to provide that, but it doesn&#39;t have to be a leading dot if we can think of a way which is less problematic. <div><br></div><div>I am simply spitballing here but would </div><div>1 period for enum look up</div><div>2 periods for static member lookup</div><div><br></div><div>or something similar be a solution? It doesn&#39;t use another character or keyword and it makes it clear which feature is being used.  <br><div><br></div><div>TJ</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 4, 2016 at 4:22 PM, Howard Lovatt via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moving away from the compiler, I like the leading dot for the programmer to distinguish static and instance members. The &#39;missing&#39; receiver natural means static to me. <div class="HOEnZb"><div class="h5"><br><br>On Tuesday, 5 April 2016, Dave Abrahams via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Mon Apr 04 2016, Joe Groff &lt;<a>swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt;&gt; On Apr 4, 2016, at 12:51 PM, Dave Abrahams &lt;<a>dabrahams@apple.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; on Mon Apr 04 2016, Joe Groff &lt;jgroff-AT-apple.com&gt; wrote:<br>
&gt;&gt;<br>
&gt;<br>
&gt;&gt;&gt;&gt; On Apr 4, 2016, at 11:44 AM, Dave Abrahams &lt;<a>dabrahams@apple.com</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; on Mon Apr 04 2016, Joe Groff &lt;jgroff-AT-apple.com&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution &lt;<a>swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; on Mon Apr 04 2016, Erica Sadun &lt;<a>swift-evolution@swift.org</a>&gt; asked:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; Can you ping me off-list or in another thread and explain what the<br>
&gt;&gt;&gt;&gt;&gt;&gt;&gt; issues are?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; All of the following make me uncomfortable with our leading-dot thang:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * The rules for lookup don&#39;t seem obvious to me.  I admit this is very<br>
&gt;&gt;&gt;&gt;&gt;&gt; personal/subjective.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * There is some evidence that people think it means something it doesn&#39;t<br>
&gt;&gt;&gt;&gt;&gt;&gt; (“enum case”), as mentioned in SE-0036.  That suggests it is a<br>
&gt;&gt;&gt;&gt;&gt;&gt; confusing feature.  That confusion may be fairly harmless so far, but<br>
&gt;&gt;&gt;&gt;&gt;&gt; still.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * The dot doesn&#39;t seem to buy enough to be worth the complexity it adds<br>
&gt;&gt;&gt;&gt;&gt;&gt; to the language; why not just let those names be looked up without the<br>
&gt;&gt;&gt;&gt;&gt;&gt; dot?  You can always disambiguate with full qualification if you have<br>
&gt;&gt;&gt;&gt;&gt;&gt; to.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Making every unqualified reference context-dependent would be<br>
&gt;&gt;&gt;&gt;&gt; impractical. `foo.bar(bas)` would become an exponential search to find<br>
&gt;&gt;&gt;&gt;&gt; a contextual type containing a `foo` which has a `bar` member that can<br>
&gt;&gt;&gt;&gt;&gt; accept an type containing a `bas` member.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I don&#39;t think I&#39;m talking about making every unqualified reference<br>
&gt;&gt;&gt;&gt; context-dependent.  When I have a context that demands an instance of a<br>
&gt;&gt;&gt;&gt; particular enum type, I think it&#39;s reasonable to look up the names in<br>
&gt;&gt;&gt;&gt; the enum without qualification, and I strongly question the value of<br>
&gt;&gt;&gt;&gt; leading-dot syntax for general static member lookup.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Therein lies the rub—*any* context an unqualified name can appear in<br>
&gt;&gt;&gt; could potentially demand an instance of a particular enum type, until<br>
&gt;&gt;&gt; the type checker rules that out. Limiting the behavior to enums<br>
&gt;&gt;&gt; doesn&#39;t simplify the implementation.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m afraid I don&#39;t understand how that&#39;s a serious problem yet.<br>
&gt;<br>
&gt; Right now, we limit the contextual lookup to places where it&#39;s<br>
&gt; syntactically asked for, using the leading dot. Without the leading<br>
&gt; dot, we&#39;d have to extend it to every unqualified name, which makes it<br>
&gt; much more likely you&#39;ll fall into problematic cases.<br>
<br>
I don&#39;t know how to evaluate whether that likelihood is a problem in<br>
practice, or not, though.<br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a>swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote><br><br></div></div><span class="HOEnZb"><font color="#888888">-- <br>-- Howard.<br>
</font></span><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>