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@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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
