[swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

[Joe Groff]

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution <swift-evolution at 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