> 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
