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. >> 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. > > Enums are only the most common place where static members of Self type > appear in numbers, but option sets also do. While this may be a matter > of taste, being able to refer to `.max`, `.infinity`, `.nan`, or other > abstract constants of numeric types in a concrete-type-agnostic way > also seems like a win to me. Agreed. Let me ask the question differently: what value does the leading `.` provide to the user of the language? -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
