on Sat Apr 09 2016, Chris Lattner <[email protected]> wrote:
> 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. 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
