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

Joe_Groff · April 5, 2016, 10:04pm

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.)

Regards, -- Erica

Adding a self literal to Swift

  • Proposal: SE-XXXX
  • Author(s): Erica Sadun
  • Status: TBD
  • Review manager: TBD
Introduction

This proposal introduces self, a new literal that expands to self.dynamicType.

This proposal was discussed on the Swift Evolution list in the [Pitch] Adding a Self type name shortcut for static member access thread.

Motivation

It is common in Swift to reference an instance's type, whether for accessing a static member or passing a type for an unsafe bitcast, among other uses. At this time, you can either fully specify a type by name or use self.dynamicType to access an instance's dynamic runtime type as a value.

struct MyStruct {
    static func staticMethod() { ... }
    func instanceMethod() {
        MyStruct.staticMethod()
        self.dynamicType.staticMethod()
    }
}

  • As type names grow large, readability suffers, for example MyExtremelyLargeTypeName.staticMember
  • Code using hardwired type names is less portable than code that automatically knows its type.
  • Renaming a type means updating any TypeName references in code.
  • Using self.dynamicType fights against Swift's goals of concision and clarity; it is both noisy and esoteric.
  • self.dynamicType.classMember and TypeName.classMember may not be synonyms in class types with non-final members.
  • Joe Groff points out, Self inside a class scope already means "the dynamic class of 'self'", not "the type this declaration statically appears within...Swift ought to allow developers to utter Self in the bodies of class methods. It would be consistent to extend that courtesy to value types, where dynamic Self always matches the static type, from that principle"
Detail Design

In this proposal, self expands to the dynamic type of self and only the dynamic type of self. Joe Groff writes, "I don't think it's all that onerous to have to write ClassName.foo if that's really what you specifically mean."

What you're describing should be spelled `Self`, IMO. I think Tim intended `#Self` to mean the *static* type the code is declared inside (which is the same as Self unless you're in a class).

-Joe

···

On Apr 5, 2016, at 3:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

Alternatives Considered

Not at this time

Acknowlegements

Thanks Sean Heber, Kevin Ballard, Joe Groff, Timothy Wood, Brent Royal-Gordon, Andrey Tarantsov, Austin Zheng

Timothy_Wood · April 5, 2016, 10:17pm

Yes, that is what I was aiming for. `#Self` would be a pretty much textual replacement just like #file, etc. That is, I could imaging it being used in a bunch of cases (not useful here, but just intending to enumerate the possible uses I see):

class Foo {
static let myClass: self.Type = self.self
static let anInstance: self = self()

static let defaultState = …

var state = self.defaultState
}

The extra bit I was suggesting for allowing passing it in as a default argument like #file is for assert/precondition would be useful to me too:

func globalFunc<SomeType: SomeProtocol>(callerType: SomeType.Type = self.self, …)

which would only be callable inside a class/struct/enum context that conformed to SomeProtocol (unless you explicitly passed a callerType that met the requirements, of course). I’ve no idea if this latter bit is hard enough or controversial enough to be its own proposal =)

-tim

···

On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:

What you're describing should be spelled `Self`, IMO. I think Tim intended `#Self` to mean the *static* type the code is declared inside (which is the same as Self unless you're in a class).

Erica_Sadun · April 5, 2016, 10:12pm

Updating. Gist here: self.md · GitHub

-- E

···

On Apr 5, 2016, at 4:04 PM, Joe Groff <jgroff@apple.com> wrote:

On Apr 5, 2016, at 3:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.)

Regards, -- Erica

Erica_Sadun · April 5, 2016, 10:21pm

Please check to ensure that the changes I just made match your expectations:

gist.github.com

https://gist.github.com/erica/c60c7d51809889f3dfd47cdb482d6227

self.md

# Expanding Swift `Self` to methods and value types

* Proposal: [SE-XXXX](https://gist.github.com/erica/5a26d523f3d6ffb74e34d179740596f7)
* Author(s): [Erica Sadun](http://github.com/erica)
* Status: TBD
* Review manager: TBD

## Introduction

This proposal introduces `Self`, an equivalent to `self.dynamicType`. It extends the use of `Self`

This file has been truncated. show original

-- E

···

On Apr 5, 2016, at 4:17 PM, Timothy Wood <tjw@me.com> wrote:

On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

What you're describing should be spelled `Self`, IMO. I think Tim intended `#Self` to mean the *static* type the code is declared inside (which is the same as Self unless you're in a class).

Yes, that is what I was aiming for. `#Self` would be a pretty much textual replacement just like #file, etc. That is, I could imaging it being used in a bunch of cases (not useful here, but just intending to enumerate the possible uses I see):

Erica_Sadun · April 6, 2016, 4:51pm

Pull Request 248: Expanding Swift Self to class members and value types by erica · Pull Request #248 · apple/swift-evolution · GitHub

Within a class scope, Self means "the dynamic class of self". This proposal extends that courtesy to value types, where dynamic Self will match a construct's static type, and to the bodies of class members, where it may not. It also introduces a static variation, self that expands to static type of the code it appears within.

This proposal was discussed on the Swift Evolution list in the [Pitch] Adding a Self type name shortcut for static member access <http://thread.gmane.org/gmane.comp.lang.swift.evolution/13708/focus=13712> thread.

Thanks, -- E

···

On Apr 5, 2016, at 4:04 PM, Joe Groff <jgroff@apple.com> wrote:

On Apr 5, 2016, at 3:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.)

Regards, -- Erica

Timothy_Wood · April 5, 2016, 10:28pm

That looks good to me — thanks Erica!

-tim

···

On Apr 5, 2016, at 3:21 PM, Erica Sadun <erica@ericasadun.com> wrote:

Please check to ensure that the changes I just made match your expectations:

self.md · GitHub

jazzbox · April 6, 2016, 7:11am

I am using a typealias for this:

struct MyStruct {
private typealias _Self = MyStruct

    static func staticMethod() { print("staticMethod") }

    func instanceMethod() {
        _Self.staticMethod()
    }
}

···

> On Apr 5, 2016, at 4:17 PM, Timothy Wood<tjw@me.com(mailto:tjw@me.com)>wrote:
>
> > On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > What you're describing should be spelled `Self`, IMO. I think Tim intended `#Self` to mean the *static* type the code is declared inside (which is the same as Self unless you're in a class).
>
> Yes, that is what I was aiming for. `#Self` would be a pretty much textual replacement just like #file, etc. That is, I could imaging it being used in a bunch of cases (not useful here, but just intending to enumerate the possible uses I see):
Please check to ensure that the changes I just made match your expectations:

self.md · GitHub

-- E

hartbit · April 7, 2016, 6:09am

There's something I find very confusing with this proposal, and it's how Self is already used in protocol definitions to represent the STATIC type of the type that conforms to the protocol. I think people will be potentially very confused by how Self represents different types in different contexts:

protocol Copyable {
func copy() -> Self
}

class Animal : Copyable {
    init() {}
    func copy() -> Animal {
        return Self.init()
    }
}

class Cat : Animal {}

In the previous sample, wouldn't it be confusing to people if Self in the protocol means Animal in the Animal type, but Self in the Animal type may mean Cat?

···

Sent from my iPad

On 06 Apr 2016, at 18:51, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 5, 2016, at 4:04 PM, Joe Groff <jgroff@apple.com> wrote:

On Apr 5, 2016, at 3:02 PM, Erica Sadun <erica@ericasadun.com> wrote:

As the discussion seems to be quieting down, I've tried to summarize the on-list discussion and distill it into a preliminary proposal draft. Please let me know if this covers what you think it should or if I've entirely missed the mark. (It wouldn't be the first time.)

Regards, -- Erica

Pull Request 248: Expanding Swift Self to class members and value types by erica · Pull Request #248 · apple/swift-evolution · GitHub

Within a class scope, Self means "the dynamic class of self". This proposal extends that courtesy to value types, where dynamic Self will match a construct's static type, and to the bodies of class members, where it may not. It also introduces a static variation, self that expands to static type of the code it appears within.

This proposal was discussed on the Swift Evolution list in the [Pitch] Adding a Self type name shortcut for static member access thread.

Thanks, -- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

dabrahams · April 6, 2016, 4:12pm

I am using a typealias for this:

struct MyStruct {
    private typealias _Self = MyStruct

    static func staticMethod() { print("staticMethod") }

    func instanceMethod() {
        _Self.staticMethod()
    }
}

Yes, you can do that. It's cumbersome, and you can't use your private
typealias in any public method signatures.

···

on Wed Apr 06 2016, "Bernd Ohr (jazzbox) via swift-evolution" <swift-evolution@swift.org> wrote:

> On Apr 5, 2016, at 4:17 PM, Timothy Wood<tjw@me.com(mailto:tjw@me.com)>wrote:
>
> > On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
> > What you're describing should be spelled `Self`, IMO. I think
> > Tim intended `#Self` to mean the *static* type the code is
> > declared inside (which is the same as Self unless you're in a
> > class).
>
> Yes, that is what I was aiming for. `#Self` would be a pretty much
> textual replacement just like #file, etc. That is, I could imaging
> it being used in a bunch of cases (not useful here, but just
> intending to enumerate the possible uses I see):
Please check to ensure that the changes I just made match your expectations:

self.md · GitHub

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

akashivskyy · April 6, 2016, 8:51am

+1 for Self and the proposal.

Pozdrawiam – Regards,
Adrian Kashivskyy

···

Wiadomość napisana przez Bernd Ohr (jazzbox) via swift-evolution <swift-evolution@swift.org> w dniu 06.04.2016, o godz. 09:11:

I am using a typealias for this:

struct MyStruct {
   private typealias _Self = MyStruct

   static func staticMethod() { print("staticMethod") }

   func instanceMethod() {
       _Self.staticMethod()
   }
}

On Apr 5, 2016, at 4:17 PM, Timothy Wood<tjw@me.com(mailto:tjw@me.com)>wrote:

On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
What you're describing should be spelled `Self`, IMO. I think Tim intended `#Self` to mean the *static* type the code is declared inside (which is the same as Self unless you're in a class).

Yes, that is what I was aiming for. `#Self` would be a pretty much textual replacement just like #file, etc. That is, I could imaging it being used in a bunch of cases (not useful here, but just intending to enumerate the possible uses I see):

Please check to ensure that the changes I just made match your expectations:

self.md · GitHub

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Joe_Groff · April 7, 2016, 3:28pm

Protocol conformances are inherited, so that's not a valid conformance, and protocol Self is synonymous with class Self when a class conforms. Animal.copy() would have to return Self to conform to Copyable.

-Joe

···

On Apr 6, 2016, at 11:09 PM, David Hart <david@hartbit.com> wrote:

There's something I find very confusing with this proposal, and it's how Self is already used in protocol definitions to represent the STATIC type of the type that conforms to the protocol. I think people will be potentially very confused by how Self represents different types in different contexts:

protocol Copyable {
    func copy() -> Self
}

class Animal : Copyable {
    init() {}
    func copy() -> Animal {
        return Self.init()
    }
}

class Cat : Animal {}

In the previous sample, wouldn't it be confusing to people if Self in the protocol means Animal in the Animal type, but Self in the Animal type may mean Cat?

jeremyp · April 6, 2016, 9:15am

I think I would be -1 on this.

The proposal is that there be two names, Self and self that refer to different objects but are differentiated only by the capitalisation of the first letter and these could be mixed in the same context.

I think this would make code that uses both harder to read. If typing ‘self.dynamicType’ is too onerous, how about shortening it in a different way? Why, for instance is ‘self.' mandatory? Alternatively, why is it ‘dynamicType’ and not just ‘type’?

···

On 6 Apr 2016, at 10:51, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:

+1 for Self and the proposal.

Pozdrawiam – Regards,
Adrian Kashivskyy

Wiadomość napisana przez Bernd Ohr (jazzbox) via swift-evolution <swift-evolution@swift.org> w dniu 06.04.2016, o godz. 09:11:

I am using a typealias for this:

struct MyStruct {
   private typealias _Self = MyStruct

   static func staticMethod() { print("staticMethod") }

   func instanceMethod() {
       _Self.staticMethod()
   }
}

On Apr 5, 2016, at 4:17 PM, Timothy Wood<tjw@me.com(mailto:tjw@me.com)>wrote:

On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
What you're describing should be spelled `Self`, IMO. I think Tim intended `#Self` to mean the *static* type the code is declared inside (which is the same as Self unless you're in a class).

Yes, that is what I was aiming for. `#Self` would be a pretty much textual replacement just like #file, etc. That is, I could imaging it being used in a bunch of cases (not useful here, but just intending to enumerate the possible uses I see):

Please check to ensure that the changes I just made match your expectations:

self.md · GitHub

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Brent_Royal-Gordon · April 6, 2016, 10:07am

Alternatively, why is it ‘dynamicType’ and not just ‘type’?

I suspect this has something to do with the 27 methods in various OS X frameworks named `type`. (To be fair, 17 of those are in WebKit's DOM classes.)

What I'm less sure about is why it's not a free function instead. Other than the `dynamicType` and `self` pseudo-properties, I'm not aware of any members which are present on all types. We might be better off making `dynamicType` a free `typeof(_:)` function (or should it be `type(of:)`? are `sizeof` and friends changing?) and `self` a free `identity(_:)` function; these would make them non-magical parts of the language, which would be kind of neat.

···

--
Brent Royal-Gordon
Architechies

dabrahams · April 6, 2016, 4:14pm

Alternatively, why is it ‘dynamicType’ and not just ‘type’?

I suspect this has something to do with the 27 methods in various OS X
frameworks named `type`. (To be fair, 17 of those are in WebKit's DOM
classes.)

Really, no. It's because something's static type is a useful
distinction from its dynamic type, and this clarifies which one you're getting.

···

on Wed Apr 06 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

What I'm less sure about is why it's not a free function
instead. Other than the `dynamicType` and `self` pseudo-properties,
I'm not aware of any members which are present on all types. We might
be better off making `dynamicType` a free `typeof(_:)` function (or
should it be `type(of:)`? are `sizeof` and friends changing?) and
`self` a free `identity(_:)` function; these would make them
non-magical parts of the language, which would be kind of neat.

--
Dave

dabrahams · April 6, 2016, 4:16pm

I think I would be -1 on this.

The proposal is that there be two names, Self and self that refer to
different objects but are differentiated only by the capitalisation of
the first letter and these could be mixed in the same context.

No, Self would not refer to an object; Self is a type alias. Self.self
is the metatype object that you might be thinking of.

I think this would make code that uses both harder to read. If typing
‘self.dynamicType’ is too onerous, how about shortening it in a
different way? Why, for instance is ‘self.' mandatory? Alternatively,
why is it ‘dynamicType’ and not just ‘type’?

That's a completely different beast; not useful in the same contexts.
For example, you can't write

var x: self.dynamicType

but you could write

var x: Self

···

on Wed Apr 06 2016, Jeremy Pereira <swift-evolution@swift.org> wrote:

On 6 Apr 2016, at 10:51, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:

+1 for Self and the proposal.

Pozdrawiam – Regards,
Adrian Kashivskyy

Wiadomość napisana przez Bernd Ohr (jazzbox) via swift-evolution <swift-evolution@swift.org> w dniu 06.04.2016, o godz. 09:11:

I am using a typealias for this:

struct MyStruct {
   private typealias _Self = MyStruct

   static func staticMethod() { print("staticMethod") }

   func instanceMethod() {
       _Self.staticMethod()
   }
}

On Apr 5, 2016, at 4:17 PM, Timothy Wood<tjw@me.com(mailto:tjw@me.com)>wrote:

On Apr 5, 2016, at 3:04 PM, Joe Groff via swift-evolution<swift-evolution@swift.org(mailto:swift-evolution@swift.org)>wrote:
What you're describing should be spelled `Self`, IMO. I think
Tim intended `#Self` to mean the *static* type the code is
declared inside (which is the same as Self unless you're in a
class).

Yes, that is what I was aiming for. `#Self` would be a pretty
much textual replacement just like #file, etc. That is, I could
imaging it being used in a bunch of cases (not useful here, but
just intending to enumerate the possible uses I see):

Please check to ensure that the changes I just made match your expectations:

self.md · GitHub

-- E

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

jeremyp · April 7, 2016, 11:30am

I think I would be -1 on this.

The proposal is that there be two names, Self and self that refer to
different objects but are differentiated only by the capitalisation of
the first letter and these could be mixed in the same context.

No, Self would not refer to an object; Self is a type alias. Self.self
is the metatype object that you might be thinking of.

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.

I think this would make code that uses both harder to read. If typing
‘self.dynamicType’ is too onerous, how about shortening it in a
different way? Why, for instance is ‘self.' mandatory? Alternatively,
why is it ‘dynamicType’ and not just ‘type’?

That's a completely different beast; not useful in the same contexts.
For example, you can't write

var x: self.dynamicType

But the _proposal_ is that `Self` can be used as an alias for `self.dynamicType`. I have no problem with using `Self` in places where a type is expected (well, no serious problem given it is already a done deal), but the proposal says “This proposal introduces Self, an equivalent to self.dynamicType.”

So you could have (in function bodies)

    self.foo() // invoke an instance method
    Self.bar() // invoke a class method, same as self.dynamicType.bar()
    Self.foo() // invokes a class method with the same name as the foo instance method

They mean different things and yet are distinguished only by the capitalisation of the letter S. I’m not objecting to a shorthand for self.dynamicType although I don’t agree with the proposal that self.dynamicType “fights against Swift’s goals of concision and clarity”, I only object to one that looks very similar to `self`.

···

On 6 Apr 2016, at 18:16, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Wed Apr 06 2016, Jeremy Pereira <swift-evolution@swift.org> wrote:

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Brent_Royal-Gordon · April 7, 2016, 12:17pm

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.

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.

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.

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

* * *

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.

···

--
Brent Royal-Gordon
Architechies

Erica_Sadun · April 7, 2016, 2:05pm

I prefer the consistency that it be available across types without exception more than I care that the functionality is duplicated. Plus if Swift eventually introduces derived value types, it may play a bigger role.

http://thread.gmane.org/gmane.comp.lang.swift.evolution/12644/
http://thread.gmane.org/gmane.comp.lang.swift.evolution/10652
http://thread.gmane.org/gmane.comp.lang.swift.evolution/153

-- E

···

On Apr 7, 2016, at 6:17 AM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
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.

jeremyp · April 7, 2016, 3:02pm

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.

You don't understand it correctly.

Having read your email, I’m pretty sure I do, and my problem with it remains.

`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() {}
  }

It’s not _really_ strange. The type of new cannot be known at compile time, only that it is some subclass of Foo (or Foo itself of course).

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.

Is it more readable? Has anybody done any objective testing?

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

let new: Self = Self()

And that is certainly not more readable than the line it replaces. The line it replaces tells me explicitly that I am creating a new object of the same type as self. This does not. The casual reader might easily assume that you will get an object of type Foo.

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

I’m not wild about that either (especially as my autocomplete seems to go for the type before the variable every time) and if you used a variable called `string` in the same context as a lot of static methods on `String` it would suffer from the same problem that I am concerned about wrt readability.

···

On 7 Apr 2016, at 14:17, Brent Royal-Gordon <brent@architechies.com> wrote:

JetForMe · March 12, 2019, 8:26am

Having read SE-0088 and skimmed through this discussion, it's not clear to me that this Self would support what I'm really hoping for, which is the ability to define a method on a base class (or an extension of a base class) that can return an instance of a derived class and take advantage of Swift’s type inference in the process (example here):

extension
NSManagedObject
{
    class func
    all(inMOC: NSManagedObjectContext,
            predicateFormat inPredicateFormat: String,
            _ inArgs: CVarArg...)
        throws
        -> [Self]
    {
        let entity = self.entity(inMOC: inMOC)
        let req = NSFetchRequest<Self>()
        req.entity = entity
        
        let pred = NSPredicate(format: inPredicateFormat, argumentArray: inArgs)
        req.predicate = pred
        
        return try inMOC.fetch(req) as [Self]
    }
}

class MyEntity : NSManagedObject {}

let myEntities = MyEntity.all(inMOC: moc, predicateFormat: : "foo == %d", someInt)
// myEntities is inferred to be of type [MyEntity]

In this use, Self is the static type of the derived usage.