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

[Erica Sadun]

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.)

Regards,  -- Erica

Adding a #Self literal to Swift

Proposal: SE-XXXX <https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7>
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
 <https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227#introduction>Introduction

This proposal introduces #Self, a new literal that expands to self.dynamicType.

This proposal was discussed on the Swift Evolution list in the [Pitch] Adding a Self type name shortcut for static member access <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708/focus=13712> thread.

 <https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227#motivation>Motivation

It is common in Swift to reference an instance's type, whether for accessing a static member or passing a type for an unsafe bitcast, among other uses. At this time, you can either fully specify a type by name or use self.dynamicType to access an instance's dynamic runtime type as a value. 

struct MyStruct {
    static func staticMethod() { ... }
    func instanceMethod() {
        MyStruct.staticMethod()
        self.dynamicType.staticMethod()
    }
}
As type names grow large, readability suffers, for example MyExtremelyLargeTypeName.staticMember
Code using hardwired type names is less portable than code that automatically knows its type.
Renaming a type means updating any TypeName references in code.
Using self.dynamicType fights against Swift's goals of concision and clarity; it is both noisy and esoteric.
self.dynamicType.classMember and TypeName.classMember may not be synonyms in class types with non-final members.
Joe Groff points out, Self inside a class scope already means "the dynamic class of 'self'", not "the type this declaration statically appears within...Swift ought to allow developers to utter Self in the bodies of class methods. It would be consistent to extend that courtesy to value types, where dynamic Self always matches the static type, from that principle"
 <https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227#detail-design>Detail Design

In this proposal, #Self expands to the dynamic type of self and only the dynamic type of self. Joe Groff writes, "I don't think it's all that onerous to have to write ClassName.foo if that's really what you specifically mean."

 <https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227#alternatives-considered>Alternatives Considered

Not at this time

 <https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227#acknowlegements>Acknowlegements

Thanks Sean Heber, Kevin Ballard, Joe Groff, Timothy Wood, Brent Royal-Gordon, Andrey Tarantsov, Austin Zheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/b775c8a2/attachment.html>