On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution <[email protected]> wrote: >> On Apr 4, 2016, at 11:17 AM, Erica Sadun <[email protected]> wrote: >>> On Apr 4, 2016, at 12:13 PM, Joe Groff <[email protected]> wrote: >>> >>>> >>>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via swift-evolution >>>> <[email protected]> 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. -Chris _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
