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

[Thorsten Seitz]

> Am 23.04.2016 um 06:56 schrieb Brent Royal-Gordon <brent at architechies.com>:
> 
>>> Having said all this, now that we have `#Self`, I'm wondering if we still want `Self` in value types. The two are *exactly* equivalent in value types as far as I can tell, and `Self` in classes implies dynamic behavior which is not supported by value types. The use of `Self` in class member bodies is a clean win, the existence of `#Self` is a clean win, but I'm not sure we need the value type thing too.
>> 
>> If subtyping for value types will be introduced someday (there has been considerable interest for that already) `Self` would make sense for value types, too, wouldn't it?
> 
> Sorry for the delay answering this; I have been (and will continue to be) rather busy.

No problem, don’t worry! As you see I’m having similar problems :-)


> It depends on the form of the subtyping support. If "subtype" just means "implicit conversion without sharing compatible representations", as having Float be a subtype of Double would be, that wouldn't necessarily make much sense. But if it's some kind of pseudo-subtyping system (though how would that work with the non-reference-based representation of structs, I don't know), then that would perhaps make more sense.

Thinking more about it I realize that it is probably only possible to have implementation inheritance without having real subtyping because a sub-struct would require more space in memory and therefore cannot be used in places of its super-struct. Is that what you mean by pseudo-subtyping?

So, you are probably right that Self does not make sense in value types.

An alternative might be introducing references for value types but this might complicate the language more than we would like. In that case Self would apply to the dynamic type of a reference (like for classes).

-Thorsten