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

[David Waite]

I believe the confusion comes from language references only using the leading dot to access enumerated values, and not to access an option set implementation or something like UIColor.

I can’t speak to the compiler processing impact or language impact of potential conflicts of looking these up without the leading dot. I can see how it would be confusing for people to have a very terse syntax for looking up static members on *other* types, and expecting either that same terse syntax or something comparable for referring to static members on their *own* type. Such syntax would have to tread softly on distinguishing static vs dynamic type resolution for looking up said members.

-DW


> On Apr 4, 2016, at 12:05 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> * 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.
> 
> * Static members generally are too verbose to access from within members
>  of a type (`Self.x` doesn't work; you have to write out
>  `TheFullTypeName.x`), and leading-dot doesn't give the ability to do
>  so. If we're going to have a special syntax for accessing static
>  members, it should *at least* solve this problem.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160404/4cdfcdfb/attachment.html>