Swift Protocol Inheritance & Generic functions

Question

Consider the following playground:

import Foundation

protocol StringInitable {
    init( string:String )
}

class A : StringInitable {
    var stored:String

    required init ( string:String ) {
        stored = string
    }
}

class B : A /*, StringInitable */ {
    var another_stored:String

    required init ( string:String ) {
        another_stored = "B-store"

        super.init(string: string)
    }
}

func maker<T:StringInitable>(string:String) -> T {
    return T(string: string)
}

let instanceA = A(string: "test-maker-A")
let instanceB = B(string: "test-maker-B")

let makerA:A = maker("test-maker-A")
let makerB:B = maker("test-maker-B")

let typeInstanceA = _stdlib_getTypeName(instanceA)
let typeMakerA = _stdlib_getTypeName(makerA)

let typeInstanceB = _stdlib_getTypeName(instanceB)
let typeMakerB = _stdlib_getTypeName(makerB)

From the results the compiler seems to have inferred the correct types but has failed to call the correct initializers. How come I have to explicitly implement StringInitable in the B-class (test by removing the comment in the B class definition) to have the generic function "maker" call the correct initializer?

Answer 1

That smells like a compiler bug for one simple reason: makerB is a variable of B type, but it is assigned an instance of A. This should not be possible, and in fact if you try to print, and more generally to access to, the another_stored property of the makerB variable, a runtime exception is raised, and I wouldn't expecting nothing else.

That's because if B is a subclass of A, an instance of A cannot be assigned to a variable of B type (whereas the opposite is possible).

Assigning a variable of A type to a variable of B type is possible though, but only under these conditions:

• an explicit downcast from A to B is done (the compiler should error otherwise)
• the instance referenced by the A variable is actually an instance of B (a runtime exception should be raised otherwise)

Note that the compiler didn't just fail to call the correct initializer - it called the initializer of another class