[swift-evolution] [Review] SE-0068: Expanding Swift Self to class members and value types

[Jeremy Pereira]

> On 20 Apr 2016, at 18:16, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 	* What is your evaluation of the proposal?

-1

Addressing the issues cited in the proposal:

> 	• dynamicType remains an exception to Swift's lowercased keywords rule. This change eliminates a special case that's out of step with Swift's new standards.


Except for the fact that `dynamicType` cannot be used with implicit self, it has always felt more like a property to me than a keyword and the capitalisation is therefore not out of place. The camel case does not jar for me in the same way that writing `someInstance.Self` would.

NB the keyword `Self` would also violate the all-lowercase keyword rule.

> 	• Self is shorter and clearer in its intent. It mirrors self, which refers to the current instance.

It is undeniably shorter, but it is not clearer in intent. `self.dynamicType` clearly and explicitly tells us we are referring to the runtime type of the instance. `Self` does not. Furthermore, it overloads the word with two subtly different meanings depending on context. 

> 	• It provides an easier way to access static members. As type names grow large, readability suffers. MyExtremelyLargeTypeName.staticMember is unwieldy to type and read.

I reject the assertion that readability suffers with large type names. `NSApplicationDelegate` is much more readable than `NSAppDlgt` for example.

Furthermore, this proposal does not address the length of `MyExtremelyLargeTypeName.someMember()` since that might not be the same method as `Self.someMember()` If you explicitly want the `someMember()` defined by `MyExtremelyLargeTypeName` you still have to spell it out in case it is a class function and the dynamic type is a subclass.  

> 	• Code using hardwired type names is less portable than code that automatically knows its type.

And how does `self.dynamicType` fail here?

> 	• Renaming a type means updating any TypeName references in code.

This is the same point as the previous one.

> 	• Using self.dynamicType fights against Swift's goals of concision and clarity in that it is both noisy and esoteric.

I disagree. `self.dynamicType` is a clear and concise description of the object it represents.

Another observation: the proposal omits the “Impact own Existing Code” section. I think this would be a breaking change for a lot of existing code.

Also, I’m disappointed that no alternatives seem to have been documented.


> 	* Is the problem being addressed significant enough to warrant a change to Swift?

No.

> 	* Does this proposal fit well with the feel and direction of Swift?

No, unless the direction of Swift is to go for maximum terseness at the expense of clarity.

> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

In Objective-C you can write [self class] to get the runtime class of an object. I think that is a better choice of name. In Swift the analogue would probably be `self.type`. Was this considered?


> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I’ve been following the thread.