> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution > <[email protected]> wrote: > > >> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >>> 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 would agree that Self should remain the dynamic version, but adding > StaticSelf (however it is spelled) adds the safety of being able to refactor > code w/o forgetting to rename an explicit class name. It adds the ability to > more clearly express what you mean (“the containing class/struct, whatever it > happens to be”), and it would reduce effort while reading code (in that you > could see quickly that it was StaticSelf instead of having to look to see > whether it was the same name as the enclosing type every time you read the > code).
But if you don’t want subclasses to override it then why are you making it internal/public in the first place? I’m not sure the only-classes case of exposing a class/static publicly but also not wanting subclasses to override it justifies a new language construct. Accessing these things via Self (aka self.dynamicType) seems good enough to me. Russ
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
