[swift-evolution] My personal beef with leading-dot syntax

[Dave Abrahams]

on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:

>> On Apr 4, 2016, at 11:44 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>> 
>> 
>> on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote:
>> 
>
>>>> On Apr 4, 2016, at 11:05 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> 
>>>> on Mon Apr 04 2016, Erica Sadun <swift-evolution at swift.org> asked:
>>>> 
>>> 
>>>>> Can you ping me off-list or in another thread and explain what the
>>>>> issues are?
>>>> 
>>>> All of the following make me uncomfortable with our leading-dot thang:
>>>> 
>>>> * The rules for lookup don't seem obvious to me.  I admit this is very
>>>> personal/subjective.
>>>> 
>>>> * There is some evidence that people think it means something it doesn't
>>>> (“enum case”), as mentioned in SE-0036.  That suggests it is a
>>>> confusing feature.  That confusion may be fairly harmless so far, but
>>>> still.
>>>> 
>>>> * The dot doesn't seem to buy enough to be worth the complexity it adds
>>>> to the language; why not just let those names be looked up without the
>>>> dot?  You can always disambiguate with full qualification if you have
>>>> to.
>>> 
>>> Making every unqualified reference context-dependent would be
>>> impractical. `foo.bar(bas)` would become an exponential search to find
>>> a contextual type containing a `foo` which has a `bar` member that can
>>> accept an type containing a `bas` member.
>> 
>> I don't think I'm talking about making every unqualified reference
>> context-dependent.  When I have a context that demands an instance of a
>> particular enum type, I think it's reasonable to look up the names in
>> the enum without qualification, and I strongly question the value of
>> leading-dot syntax for general static member lookup.
>
> Therein lies the rub—*any* context an unqualified name can appear in
> could potentially demand an instance of a particular enum type, until
> the type checker rules that out. Limiting the behavior to enums
> doesn't simplify the implementation.

I'm afraid I don't understand how that's a serious problem yet.

>> I would normally
>> never think of using it that way—because, guess what? I think of
>> leading-dot as a notation for enums like everybody else does—and I don't
>> think there are any important idioms it supports, that couldn't be
>> equally well handled by something like `Self.x` if we were allowed to
>> use it.
>
> Enums are only the most common place where static members of Self type
> appear in numbers, but option sets also do. While this may be a matter
> of taste, being able to refer to `.max`, `.infinity`, `.nan`, or other
> abstract constants of numeric types in a concrete-type-agnostic way
> also seems like a win to me.

Agreed.  Let me ask the question differently: what value does the 
leading `.` provide to the user of the language?

-- 
Dave