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

Howard Lovatt howard.lovatt at gmail.com
Mon Apr 4 15:22:16 CDT 2016


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 <javascript:;>>
> wrote:
>
> >> On Apr 4, 2016, at 12:51 PM, Dave Abrahams <dabrahams at apple.com
> <javascript:;>> 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
> <javascript:;>> 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 <javascript:;>> wrote:
> >>>>>>
> >>>>>>
> >>>>>> on Mon Apr 04 2016, Erica Sadun <swift-evolution at swift.org
> <javascript:;>> 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 <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>


-- 
-- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/0e3aef88/attachment.html>


More information about the swift-evolution mailing list