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

[Austin Zheng]

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 at swift.org> wrote:
> 
> 
>> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution