Attachment: Download

duplicates:

• SR-10285 Subclass of a class that conforms to a protocol and extends NSObject is not instantiate correctly

Issue Description:

This came up on Stack Overflow. There are some complications that I'll get to in a moment; because of those complications, I am uncertain what the bug is or whether there's a bug. I just know that I'm surprised.

In the following playground code, a generic class, Wrapper, is asked to instantiate its parameterized type. The type is resolved explicitly to B, a subclass of A. In Xcode 9.2, it instantiates B, as expected. But in Xcode 10.2.1 the generic instantiates A instead.

protocol P {
    init()
    func doThing()
}
class Wrapper<T:P> {
    func go() {
        T().doThing()
    }
}
class A : NSObject, P {
    required override init() {}
    func doThing() {
        print("A")
    }
}
class B : A {
    required override init() {}
    override func doThing() {
        print("B")
    }
}
Wrapper<B>().go()

The result is that we print B in Xcode 9.2 but we print A in Xcode 10.2.1. I find that result so unbelievable that I have included screen shots to prove it.

Now for the further complications. The following remarks apply to Xcode 10.2.1.

• The involvement of the protocol, which constrains the parameterized type, is crucial. If we constrain the generic type to A with Wrapper<T:A> instead of Wrapper<T:P>, we get B instead of A.

• Or, if we keep Wrapper<T:P> but we change the protocol P declaration to @objc, we get B instead of A.

• Or, if we don't make P @objc, but we eliminate class A's inheritance from NSObject (and the word override from A's init declaration), making A a base class, we get B instead of A.

These considerations suggest that the involvement of Objective-C is central somehow.