[swift-dev] Type inference of functions with more than one statement

[Slava Pestov]

Hi Ross,

Swift's type inference operates at the level of a single statement. This is why we can infer parameter and return types for single-expression closures. While conceptually, it would not be a huge change to the type checker algorithm to support global type inference for closures and other functions consisting of multiple statements, we feel that philosophically, this is not a direction the language should take. Global type inference will further exacerbate performance problems with type checking, as well as make it harder to produce good diagnostics.

So really, this has less to do with closures per se, and more with just the general design and philosophy of the type checker.

(Please correct me if I've mis-represented anything here -- this is my recollection of listening in on various discussions in the past).

> On Jul 8, 2016, at 10:00 AM, Ross LeBeau via swift-dev <swift-dev at swift.org> wrote:
> 
> It seems that the compiler fails to infer the type of an anonymous function if the function contains more than one statement. For example, this works:
> 
> let a = [[1,2],[3],[4,5,6]]
> var b: [Int]
> b = a.flatMap { elem in
>   return elem
> }
> 
> But this fails with an error "cannot convert return expression of type '[Int]' to return type 'Int?'":
> 
> b = a.flatMap { elem in
>   print(elem)
>   return elem
> }
> 
> And, of course, if you explicitly type the function, it works again:
> 
> b = a.flatMap { (elem: [Int]) -> [Int] in
>   print(elem)
>   return elem
> }
> 
> Greg Titus informed me that this is due to a heuristic in the compiler where it only imports the outer context when type-checking anonymous functions with a single statement. Before we knew this, I and others, found it perplexing that out of two functions that return the same value, one will compile and the other will not.
> 
> Are there any plans to extend the context of type-checking in the case of a failure like this? If not, is it something to consider? It seems like a difficult problem to solve without rather advanced knowledge of what's going on.
> 
> Also if this has already been brought up, forgive me, I just subscribed to this list and a quick search of the archives didn't get any hits :)
> 
> -- 
> Ross
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev