Protocol types with class adoption limitation in generics

[francuim-d]

Seems like in Swift 5.7 protocol types with class adoption limitation no longer acts like actual class type in generics

protocol Colorable: UIView { }

extension UIView {
    func subviews<T: UIView>(ofType type: T.Type) -> [T] {
        subviews.compactMap { $0 as? T }
    }
}

let view = UIView()
let colorableViews = view. subviews(ofType: Colorable.self)

Actial behavior
The code does not compiles with error: Instance method 'subviews(ofType:)' requires that 'any Colorable' inherit from 'AnyObject'

Expected behavior
The code compiles and correctly finds the subviews of the specified type.

Environment

• macOS 12.6
• Xcode 14.0.1 (14A400)

Additional context
That exact code compiles and works fine with Xcode 13.3.1

[theblixguy]

I think you just need to change the type of the argument from T.Type to Any.Type. Also, since the argument is not actually used, you can drop the type label and just do ofType _: Any.Type.

With this small change, your code should compile as expected.

Ignore, I misunderstood the question.

[francuim-d]

You just need to change the type of the argument from T.Type to Any.Type. Also, since the argument is not actually used, you can drop the type label and just do ofType _: Any.Type.

With this small change, your code should compile as expected.

If I replace T.Type with Any.Type then I will lose the ability to specify a concrete type using the function parameter.
The method of specifying a concrete type with a function parameter is used here because this function is sometimes called in a context in which it cannot infer T by the return type.

And again, what confuses me is that with swift 5.6 the code is compiled and works exactly as it should.

[francuim-d]

In this thread on the Swift forum, the author faced the same problem.
https://forums.swift.org/t/weird-error-from-the-compiler-when-using-xcode-14/60119

[theblixguy]

Ah okay, I should've looked at it more closely, sorry.

[theblixguy]

So I think this error is happening because you have a T: UIView constraint on the function, which any Colorable (which is an existential box) does not satisfy as it does not inherit from UIView (it's the type that it contains that inherits from it).

We do have an implicit mechanism to "open" the existential box, but I am unsure if it applies here.

[francuim-d]

Thanks for your reply. I studied the proposals. I understood the concept of existential types, but I wonder why this code works in swift 5.6, which already contains existential types. And is it possible to somehow write the same code that would work in swift 5.7+

[AnthonyLatsis]

This was a type safety hole. You should not be able to pass a protocol metatype P.Protocol instance P.self to this function, because a protocol metatype value is not associated with any concrete type T that conforms to the protocol or inherits from the class. Remember, the protocol itself does not inherit from the class, : C is just a requirement on Self, the conforming type. For example, the 5.5.2 compiler lets the following code through, resulting in a run-time crash.

class C {
  class func test() {
    print("Hello, World!")
  }
}
protocol P: C {}

func f1<T: C>(_: T.Type) {
  T.test()
}

f1(P.self)

What you can pass is an existential metatype P.Type instance, a run-time box that encapsulates a metatype value of a concrete type that actually conforms to the protocol:

func f2(_ p: P.Type) {
  f1(p)
}

class Sub: C, P {}
f2(Sub.self) // Hello, World!

Note
What really happens here is that p gets implicitly upcasted to C.Type before being passed to f1.

---

This is also why you cannot do let _: P.Protocol = Sub.self, unlike let _: P.Type = Sub.self.