I too would like a #Self. In my (subjective, biased) experience, sufficiently descriptive type names are usually long enough to make working with static members painfully onerous.
If there's still the risk of confusion (compile-time type versus runtime type), maybe #Self can be limited to instances where the type it references cannot change at runtime (e.g. a struct, enum, or final class). I don't know if this will actually be necessary, though - just throwing ideas out there. Austin > On Apr 5, 2016, at 9:06 AM, Joe Groff via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>> Would using another word or symbol fix that problem? >>> >>> My preference would be for there to be only one Self, and have it always be >>> the dynamic type of 'self'. Some people disagree, but I don't think it's >>> all that onerous to have to write ClassName.foo if that's really what you >>> specifically mean. >> >> I would agree that Self should remain the dynamic version, but adding >> StaticSelf (however it is spelled) adds the safety of being able to refactor >> code w/o forgetting to rename an explicit class name. It adds the ability to >> more clearly express what you mean (“the containing class/struct, whatever >> it happens to be”), and it would reduce effort while reading code (in that >> you could see quickly that it was StaticSelf instead of having to look to >> see whether it was the same name as the enclosing type every time you read >> the code). >> >> My support for StaticSelf isn’t at all about it being too hard to type >> ClassName.foo the first time, but about being able to read and maintain code >> after the fact. > > I think you have a good point with your `#Self` idea—there's definitely an > analogy there to other magic constants like #function. > >> And, of course, the argument that writing ClassName.foo isn’t onerous is >> dangerously close to an argument for dropping “.foo” with a type inferred by >> the call site... =) > > From my own experience with C++11, if it weren't for code completion, having > to utter 'EnumName::Case' over and over again when working with `enum > class`es would drive me up the wall. > > -Joe > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
