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