@swift-ci create

This is "just" factory initializers. I'm pretty sure we don't implement it properly, either—I have no idea what it means to assign to self for a class type when called from a convenience initializer.

According to @slavapestov we do implement it properly; you two can duke it out if you like.

Whether or not we implement it properly, I don't think we should optimize it. There is a correct design for this feature and this isn't it.

A library publishes a protocol that happens to do self-assignment. An application happens to make a class type conform to that protocol. They don't know about one another's internals. This will come up, and IMO it should not be needlessly inefficient.

I agree with Dave. Whether or not we expose some additional sugar for this, the underlying architectural change, where non-@objc convenience initializers do not get an initializing entry point, is something we should do before ABI stability. It's not an optimization as much as a sensible refactoring.

I forgot to point out that this isn't sound under our initializer inheritance rules.

class UnrelatedDerived: Base {
}

let x: UnrelatedDerived = .init(true)
print(x)

Comment by Ky (JIRA)

Whoops this wasn't resolved before ABI Stability

We did do the refactoring-optimization Slava talked about, and we've banned this particular incantation to avoid the unsoundness. So I think we're down to factory inits. (The code's still not 100% efficient; for some reason it's not inlining the call to init(factory:). But it's no longer doing a spare allocation.)

public protocol FactoryInitializable {}
extension FactoryInitializable {
  public init(factory me: Self) {
    self = me
  }
}

class Base : FactoryInitializable {
  fileprivate init(hidden: ()) {}
  
  public convenience init(_ one: Bool) {
    self.init(factory: one ? Derived1() as! Self : Derived2() as! Self)
  }
}

class Derived1 : Base {
  public init() { super.init(hidden: ()) }
}

class Derived2 : Base {
  public init() { super.init(hidden: ()) }
}

THANKS!