Is a solution to this actually making the leading dot mean enum lookup, full stop and allowing `Self.foo`? The case that that doesn't cover is static members on a type other than `Self`. I use it to great effect for standard instances of types, so I would appreciate *some* facility to provide that, but it doesn't have to be a leading dot if we can think of a way which is less problematic.
I am simply spitballing here but would 1 period for enum look up 2 periods for static member lookup or something similar be a solution? It doesn't use another character or keyword and it makes it clear which feature is being used. TJ On Mon, Apr 4, 2016 at 4:22 PM, Howard Lovatt via swift-evolution < [email protected]> wrote: > 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 < > [email protected]> wrote: > >> >> on Mon Apr 04 2016, Joe Groff <[email protected]> wrote: >> >> >> On Apr 4, 2016, at 12:51 PM, Dave Abrahams <[email protected]> >> wrote: >> >> >> >> >> >> on Mon Apr 04 2016, Joe Groff <jgroff-AT-apple.com> wrote: >> >> >> > >> >>>> On Apr 4, 2016, at 11:44 AM, Dave Abrahams <[email protected]> >> 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 < >> [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. >> >>> >> >>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > > -- > -- Howard. > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
