Generics in Swift – “Generic parameter 'T' could not be inferred

I’d like to return a UIViewController conforming to MyProtocol from a method, so I’m using the method signature:

func myMethod<T where T : UIViewController, T : MyProtocol>() -> T {

First thing I don’t understand: if myMethod returns e.g. a MyViewController which has to following signature, I have to force cast it:

  • “classname has no member functionname” when adding UIButton target
  • iOS ADMOB Reward based video ad failed to load
  • Swift operator “*” throwing error on two Ints
  • Randomly select 5 elements from an array list without repeating an element
  • addArc(withCenter) closing path
  • Action Button Not Appearing in Notification iOS 10
  • class MyViewController: UIViewController, MyProtocol

    I cannot simply return MyViewController() but I need to cast it like this: return MyViewController() as! T – why is this necessary?

    And the second thing: how can I use this method somewhere? I cannot simply say

    let x = myMethod() as? UIViewController

    as I get the error

    Generic parameter 'T' could not be inferred

    How can I achieve something like this? If I cast it to MyViewController it works, but I would like to avoid that of course.

    EDIT: Example

    class MyViewController : UIViewController, MyProtocol {
    protocol MyProtocol {
    func myMethod<T>() -> T where T : UIViewController, T : MyProtocol {
        return MyViewController() as! T // why is the cast necessary?

    ok, I do get one part, but why is the cast to T necessary? MyViewController is a subclass of UIViewController and conforms to the protocol, so no cast should be necessary, right?

    2 Solutions Collect From Internet About “Generics in Swift – “Generic parameter 'T' could not be inferred”

    func myMethod<T where T : UIViewController, T : MyProtocol>() -> T

    This declaration says: There exists a function called myMethod, such that myMethod returns some specific T where T is a subtype of UIViewController and also MyProtocol. This does not say what type T actually is, and it does not say that there is only one such myMethod. There can be many if there are many type that are both subclasses of UIViewController and conform to MyProtocol. Every one of those types creates a new version of myMethod (really a new solution to the assertion myMethod makes, that such a function does exist).

    This is not the same thing as:

    func myMethod() -> UIViewController

    That says: The function myMethod returns any subtype of UIViewController.

    There is no way in Swift to express “any type that is a subclass of UIViewController and is a subtype of MyProtocol.” You can only discuss a specific type that meets that criterial. Swift can’t combine classes and protocols this way; it’s just a current limitation of the language, not a deep design issue.

    The specific versus any is the issue. There are many functions that satisfy your myMethod declaration. Every T you can plug in that conforms to the rules would be a candidate. So when you say myMethod(), the compiler doesn’t know which specific T you mean.

    (I was going to expand this answer to provide it in less type-theory, more “how do you do it in code” terms, but donnywals already has an excellent version of that.)

    * To your edited question *

    func myMethod<T>() -> T where T : UIViewController, T : MyProtocol {
        return MyViewController() as! T // why is the cast necessary?

    T is a specific type decided by the caller. It is not “any type that conforms” it is “some specific, concrete type that conforms.” Consider the case that you called:

    let vc: SomeOtherViewController = myMethod()

    In this case, T is SomeOtherViewController. MyViewController is not that type, so what you’re doing with the as! cast is dangerous.

    In a method like this, returning T means you have to return T. If you return MyViewController, the return type should be MyViewController. T is a generic type that will take the form of whatever the Swift compiler can infer it to be.

    So, with your method signature, a simple implementation of the protocol and method could look like this.

    protocol MyProtocol {
        var name: String { get set }
    func myMethod<T where T : UIViewController, T : MyProtocol>() -> T {
        var vc = T() = "Hello, world"
        return vc

    So, considering your usage example:

    let x = myMethod()

    How would the compiler know what the concrete type of T is? There is nothing giving it a hint of MyViewController. The only thing we know is that whatever T is, it should be MyViewController or a subclass of it. And it should conform to MyProtocol. But this does not provide information about what the type of T should be.

    The only place where the compiler can infer what we want T to be is through the return value. All the code between <> are constraints for what T is allowed to be. -> T is the only place where T is seen outside of the constraints. So if we can somehow tell the compiler what we want myMethod to return, we have given it enough information to infer T.

    Your typecast works but I agree that it’s not very pretty. A much prettier way for the compiler to infer T is this.

    let vc: MyViewController = myMethod()

    By specifying the type of vc, the compiler understands that we want myMethod to return a MyViewController. So now T‘s type can be inferred and if we return T, we actually return MyViewController.