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


(Thorsten Seitz) #1

As I understand it, the proposal is that Self can be used as an alias to self.dynamicType, which is an object in the sense of entity in Swift but not an instance of a class or struct.
My point, though is not the exact semantics of what you call the thing that Self is but that having it and self in the same code will lead to readability issues because you can have self and Self in the same code referring to completely different things and they only differ in the case of the first letter.

You don’t understand it correctly.

Currently, Self in a class definition means “whatever subclass this object happens to be”. So if you say this:

class Parent {
        func foo() -> Self
  }

class Child: Parent {}

Then on Child, the foo() function returns Self.

Self isn’t supported in value types because, since you can’t subclass value types, it always means exactly the same thing as writing the type’s name. Self also isn’t supported in the bodies of class members because, when you call members on it, it’s equivalent to self.dynamicType. This is actually really strange, though, because it means that you can’t actually write certain types explicitly. For instance:

    class Foo {
     func foo() -> Self {
     let new = self.dynamicType.init()
   // `new` is of type Self, but you can't actually write `let new: Self`
     return new

}
required init() {}
}

What this proposal is saying is:

  • Self will be allowed in value types. It will always mean the same thing as writing the type’s name explicitly, but that’s okay; it’s more readable.

  • Self will be allowed in member bodies. This will allow you to write that new line as:

          let new: Self = Self()
    

Oh, and #Self will also be permitted, which is always literally just a shorthand for whatever type you happen to be in right now.

People seem to be okay with things like var string: String; having self be of type Self is no different.


Sounds all good to me!

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?

-Thorsten

···

Am 07. April 2016 um 14:17 schrieb Brent Royal-Gordon via swift-evolution swift-evolution@swift.org:


(Brent Royal-Gordon) #2

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.

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.

···

--
Brent Royal-Gordon
Architechies


(Thorsten Seitz) #3

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 :slight_smile:

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

···

Am 23.04.2016 um 06:56 schrieb Brent Royal-Gordon <brent@architechies.com>:


(Erica Sadun) #4

I courteously disagree for the reasons stated in the proposal:

* Self introduces consistency across types
* It’s succinct and clear, enhancing readability

It may not be especially expressive in value types but I believe it remains valuable, which is a different question.

Regardless, I believe this proposal will be delayed until the question of `Type.self` vs `Type` is first ironed out as some of the design details are predicated on how that is treated.

best regards,

— E

···

On Apr 27, 2016, at 1:51 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org> wrote:

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


(Thorsten Seitz) #5

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

I courteously disagree for the reasons stated in the proposal:

* Self introduces consistency across types
* It’s succinct and clear, enhancing readability

It may not be especially expressive in value types but I believe it remains valuable, which is a different question.

Oops, you are right, of course. Too tired, should catch some sleep now...

-Thorsten

···

Am 27.04.2016 um 22:00 schrieb Erica Sadun <erica@ericasadun.com>:

On Apr 27, 2016, at 1:51 PM, Thorsten Seitz via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Regardless, I believe this proposal will be delayed until the question of `Type.self` vs `Type` is first ironed out as some of the design details are predicated on how that is treated.

best regards,

— E