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

[T.J. Usiyan]

Is a solution to this actually making the leading dot mean enum lookup,
full stop and allowing `Self.foo`? The case that that doesn'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't have to be a leading dot if we can think of a
way which is less problematic.

I am simply spitballing here but would
1 period for enum look up
2 periods for static member lookup

or something similar be a solution? It doesn't use another character or
keyword and it makes it clear which feature is being used.

TJ

On Mon, Apr 4, 2016 at 4:22 PM, Howard Lovatt via swift-evolution <
swift-evolution at swift.org> wrote:

> Moving away from the compiler, I like the leading dot for the programmer
> to distinguish static and instance members. The 'missing' receiver natural
> means static to me.
>
>
> On Tuesday, 5 April 2016, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> on Mon Apr 04 2016, Joe Groff <swift-evolution at swift.org> wrote:
>>
>> >> On Apr 4, 2016, at 12:51 PM, 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: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.
>> >
>> > Right now, we limit the contextual lookup to places where it's
>> > syntactically asked for, using the leading dot. Without the leading
>> > dot, we'd have to extend it to every unqualified name, which makes it
>> > much more likely you'll fall into problematic cases.
>>
>> I don't know how to evaluate whether that likelihood is a problem in
>> practice, or not, though.
>>
>> --
>> Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
>
> --
> -- Howard.
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/7dec70b3/attachment.html>