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

[Erica Sadun]

> On Apr 20, 2016, at 11:16 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Swift community,
> 
> The review of "SE-0068: Expanding Swift Self to class members and value types" begins now and runs through April 25. The proposal is available here:
> 
> 	https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>


RELATED DISCUSSIONS

* Design Team feedback <http://article.gmane.org/gmane.comp.lang.swift.evolution/15009> on SE-0068
* [Pitch] Adding a Self type name shortcut for static member access <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708>
* [Pitch] Rename `x.dynamicType` to `x.Self` <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14445>
* Making `.self` after `Type` optional <http://thread.gmane.org/gmane.comp.lang.swift.evolution/9059>
* Remove the Need for 'self' to Access 'dynamicType' <http://thread.gmane.org/gmane.comp.lang.swift.evolution/14173>

SHOULD .self BE REMOVED FROM TYPES

Design team notes say:

We have a proposal to remove .self on types. One reason .self exists is to avoid the mistake of writing let x = Int — the compiler will give you a weird type error later on in code if the value of x is what we today call Int.self but you meant to call the Int() initializer. Creating a metatype is not a common operation, so doing it explicitly is a good thing.

Coming back to this proposal, if we removed .self why would we want to add .Self?

Background:
From Joe Groff: "`.self` is also a bit of load-bearing duct-tape that currently supports some other parsing aspects of Swift's syntax." 
Jordan Rose adds, "Swift's type-checking engine is strong enough to merit not needing the redundant `.self` safety check." 

I personally like distinguishing `Type.self` from raw `Type` use for the reasons stated. This feature affirmatively prevents the use of `Typename` when `Typename()` is meant. In terms of this proposal, can this and should this be  retained in the language but renamed from `self`? That would update the quiz to:

Self.<runcible> // T.Type
self.Self       // T.Type
Self.Self       // T.Type.Type
self.<runcible> // == self
Which reduces at least some of the confusion. The actual runcible name could be bikeshedded.

IS `Self` THE RIGHT NAME? / SHOULD `dynamicType` require `self`

I like `Self`.  It is an existing keyword. It matches the approach used in protocols where `Self` is a placeholder for the type that conforms to that protocol. Under SE-0068, it refers to the dynamic type of the current instance. If it has to be a choice of one or the other, I'd prefer renaming `.self` and retaining `Self`. If `Self` is not the right name, I'd recommend either the `dynamictype` keyword and dropping the `self` prefix requirement or using a freestanding `dynamicType()` call. 

We have one keyword left in the language, dynamicType, which is camel cased. This proposal renames it to Self instead.

Why don’t we turn this into a standard library function? It’s not something you need so often that the member access is very valuable. Putting it in the standard library as dynamicType(_:) does still allow for that function to be implemented using compiler magic.

Another approach would be to introduce a new dynamictype keyword that doesn’t need to be accessed as a member of self, and keep Self the way it is.  Self should work in structs as a type alias.

Another perspective is that .dynamicType is just an implicitly synthesized property on all type.

Subjectively, having dynamicType as a member feels weird.

If retained as a keyword, I believe it should be lowercased to `dynamictype`. This leaves two remaining outliers (`willSet` and `didSet`). If it is re-introduced as a stdlib function, it should be `dynamicType()`.

------

ORIGINAL DESIGN TEAM FEEDBACK
SE-0068: Expanding Swift Self to class members and value types <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-04-20.html#se-0068-expanding-swift-self-to-class-members-and-value-types>
https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md <https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md>
We have one keyword left in the language, dynamicType, which is camel cased. This proposal renames it to Self instead.

In a static function today, self.dynamicType will give you a metatype but the non-member Self will not. The most useful reason to reference it is to call an initializer. It makes accessing the metatype weirder. It’s not Self.Type; that’s a type — you have to spell it Self.type.

Quiz time! What do each of the permutations mean?

Self.self
self.Self
Self.Self
self.self
The number of capital letters gives you the level of meta-ness. This is very subtle, which is probably not a good thing.

Another approach would be to introduce a new dynamictype keyword that doesn’t need to be accessed as a member of self, and keep Self the way it is.  Self should work in structs as a type alias.

Why don’t we turn this into a standard library function? It’s not something you need so often that the member access is very valuable. Putting it in the standard library as dynamicType(_:) does still allow for that function to be implemented using compiler magic.

func dynamicType<T>(_: T) -> T.Type { }
We have a proposal to remove .self on types. One reason .self exists is to avoid the mistake of writing let x = Int — the compiler will give you a weird type error later on in code if the value of x is what we today call Int.self but you meant to call the Int() initializer. Creating a metatype is not a common operation, so doing it explicitly is a good thing.

It’s weird that you can use the metatype directly to construct something or to do member access, but you can’t access it as a bare value.

Coming back to this proposal, if we removed .self why would we want to add .Self?

If you have a variable whose value is a metatype, you also keep its name in lower case. So Self makes a little less sense from that aspect too.

Another perspective is that .dynamicType is just an implicitly synthesized property on all type.

We do have other keywords that follow the dot on types, Int.Type and Fooable.Protocol, so this isn’t the only thing. Those things are magic nested types.

Subjectively, having dynamicType as a member feels weird.

If .self goes away, the four-self example above is simplified, and .Self doesn’t make sense anymore. There’s also the difference that .Self would be a runtime thing.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160421/9718b192/attachment.html>