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

[Russ Bishop]

> On Apr 5, 2016, at 7:34 AM, Timothy Wood via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160405/9cad959d/attachment.html>