Cannot Infer Generic Type in Function with Nested Closure Parameter

Using Swift
1

I was writing some Swift today and encountered a problem with generic type inference. I submitted this as a bug here, but I wanted to make sure it is in fact a bug, not something that is unavailable for a specific reason.

So anyways, let's say I have the following function:

func foo<T>(_ closure: ((T) -> Void) -> Void) {
    print(type(of: T.self)) 
}

Calling the following infers the proper type for T, String:

foo { bar in
    bar("Hello")
}
// Prints "String.Type"

The problem arises when bar is called an additional time within the closure:

foo { bar in  // Error: Generic parameter 'T' could not be inferred
    bar("Hello")
    bar("World")
}

It seems to me that if Swift can infer the type for the single invocation case, it ought to be able to infer the type for the case with multiple invocations. While this can be resolved by explicitly stating the type of bar as (String) -> Void, this can get a bit unwieldy for longer type signatures.

Is there a reason why Swift finds the multiple invocations case ambiguous? Or is it just a bug?

1 Like
2

IIRC, body of the single-expression closure is type-checked together with the expression that uses the closure. But body of more complex closure is type-checked separately (for performance reasons, I guess).

So in your first example compiler does use call to bar to obtain type information. But in the second one it tries to compute type of bar only relying on signature of foo and closure type annotations. And then will check that usage of bar agrees with computed type.

1 Like