When is the right time to push SE-0068?


(Adrian Zubarev) #1

Hi Swift community and all the great devs working on the Swift compiler. I'm wondering when it's finally time to push the implementation of SE-0068 forward?


There is a small but very useful pattern I'd like to implement on a base class type. However this pattern requires the missing feature and has no other way to workaround it (except writing the same boilerplate code over and over).

protocol Container : AnyObject {
  var coordinator: Coordinator<Self> { get }
}

class Base<T> where T : Container {
  unowned let interface: T

  init(interface: T) {
    self.interface = interface
  }
}

final class Coordinator<T> :
  Base<T> where T : Container {}

class BaseContainer : Container {
  private(set) lazy var coordinator = Coordinator<Self>(interface: self)
                                                  ^~~~
}

I re-read the rationale of the proposal and if I recall correctly someone said once that the core team decided differently then the stated in the rationale. If I'm not mistaken then there will be no Self on value types? (Please correct me if I'm wrong.) I personally would really miss it, but Self on classes is better then nothing.


Allow `self = x` in class convenience initializers
(Joe Groff) #2

The main issue here has been the poor representation of Self in the compiler. Effectively, dynamic Self ought to be treated more like a generic parameter in contexts where it's available, but it's currently treated as a special case in the few places it's supported, which is not a scalable model for generalizing where it can be used. We've made incremental progress in improving the model, but there's still a lot of work to do before this would be practical to implement.


(Adrian Zubarev) #3

Is this:

anyway important before ABI? By that I mean the things that are missing before the proposal can be implemented will be implemented before or after Swift 5 (not saying that the proposal will be implemented for Swift 5, even if I'd wish for it).


(Joe Groff) #4

There shouldn't be any ABI impact.


(Mox) #5

Swift 5.1


(Adrian Zubarev) #6

I know already for a couple month, but thank you nevertheless.


(Mox) #7

Yeah, I was thinking to have a ”conclusion” to this thread if someone searches for / stumbles upon this topic


(John Holdsworth) #8

The implementation has been merged and is available in the swift.org nightlies if you want to try it out.


#9

I like SE-0068, but it seems there are still many limits.
Coordinator<Self> is still unsupported. Self can't work with generic. That means we can't write [Self] or Self?.


(John Holdsworth) #10

There are limitations that will have to be sorted out with time including Adrian’s example. You should be able to use [Self] as an argument type on a struct however:

struct A {

    var v = 99

    static func b(a: [Self]) {
        print("Hello, World! \(a)")
    }

    func a() {
        Self.b(a: [Self.init()])
    }
}

For anything else please file a Jira with example code.


(Mox) #11

With the nightly builds, the as? Self works great in classes, awesome!

Is there already a further ticket for this?

    class Foo {
         func bar(closure: (Self) -> Void) {
            ...
          }
    }

(John Holdsworth) #12

I don’t know, feel free to add one. The limitations on Self as a type in method signatures are: only return value if it is a class. See the discussion in the PR.


(Hamish Knight) #13

I filed SR-10121 to track that :)


#14
class A {
    required init() {}
    func copy() -> Self {
        let copy = Self.init()
        return copy
    }
    
    var copied: Self {
        let copy = Self.init()
        return copy
    }
}

class B: A {
    override func copy() -> Self {
        let copy = super.copy() as! Self // supported
        return copy
    }
    
    override var copied: Self {
        let copy = super.copied as! Self // unsupported
        return copy
    }
}

(John Holdsworth) #15

Please file a Jira for this, include #Self in the title so someone can pick them up.


#16

I filed SR-10135.


(John Holdsworth) #17

Thanks