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 >> <[email protected]> wrote: >> >> >> on Mon Apr 04 2016, Erica Sadun <[email protected]> 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. I would normally never think of using it that way—because, guess what? I think of leading-dot as a notation for enums like everybody else does—and I don't think there are any important idioms it supports, that couldn't be equally well handled by something like `Self.x` if we were allowed to use it. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
