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

[Dave Abrahams]

on Sat Apr 09 2016, Chris Lattner <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:
>>> On Apr 4, 2016, at 11:17 AM, Erica Sadun <erica at ericasadun.com> wrote:
>>>> On Apr 4, 2016, at 12:13 PM, Joe Groff <jgroff at apple.com> wrote:
>>>> 
>>>>> 
>>>>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org> wrote:
>
>>>>> 
>>>>> Are there reasons that prevent using `Self` as a synonym for an instance's type name?
>>>>> 
>>>>> Consider:
>>>>> 
>>>>> struct MyStruct {
>>>>>   static func foo() { print("foo") }
>>>>>   func bar() {
>>>>>       MyStruct.foo() // works
>>>>>       self.dynamicType.foo() // works
>>>>>       Self.foo() // error
>>>>>   }
>>>>> }
>>>>> 
>>>>> Obviously, you can always name a type directly or use `self.dynamicType` but
>>>>> neither solution does any favors for readability. Both approaches obscure intent, 
>>>>> especially as type names grow large: `MyExtremelyLargeTypeName.staticMember`,
>>>>> for example. Plus, as Kevin B pointed out to me,  `self.dynamicType.classMember`  
>>>>> and `TypeName.classMember` may not be synonyms in class types with non-final members.
>>>>> 
>>>>> I'd like to see `Self.staticMember` introduced as a synonym for `TypeName.staticMember`.
>>>> 
>>>> There's the wrinkle of inheritance, as there so often is. `Self`
>>>> inside a class scope already means "the dynamic class of 'self'",
>>>> not "the type this declaration statically appears within". Now, we
>>>> really ought to allow you to utter Self in the bodies of class
>>>> methods too. It would be consistent to extend that courtesy to
>>>> value types, where dynamic `Self` always matches the static type,
>>>> from that principle.
>>>> 
>>>> -Joe
>>> 
>>> 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 agree with this, with the clarification that “Self” should be valid
> inside of structs and enums, where it is unambiguous what it refers
> to.

It is not that it's “all that onerous,” but that I (at least) was driven
to the assumption based on the uses “Self” in the language that it would
naturally work in other contexts.  As a user experience, it feels like a
violation when “Self” doesn't work where one would expect it to, and
that is compounded by the fact that the expected workaround

     private typealias _Self = NameOfTheTypeIAmDefining

doesn't work either because I can't use a private name in public APIs,
and

     public typealias Self_ = NameOfTheTypeIAmDefining

doesn't work because now I have to expose this extra name, “Self_,”
publicly.  It's a frustration I've learned to live with, and others can
too, but it's really annoying.  The annoyance doesn't go away easily,
either: I'm reminded of the frustration every time I have to work around
it.  IMO we should try to reduce the number of these repeated points of
friction when we can.

-- 
Dave