[swift-evolution] My personal beef with leading-dot syntax
david at alkaline-solutions.com
Mon Apr 4 19:55:28 CDT 2016
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.
> 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
> * 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
> * 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...
More information about the swift-evolution