Couldn't the type inference in Apple's new programming language Swift had been done more aggressive? For instance why can't the return type of a function be deduced?

func sayHello(personName: String) -> String {
   let greeting = "Hello, " + personName + "!"
   return greeting
  • $\begingroup$ how is this related to aggressivenes and not to closuredness or comprehensibility or completeness (related to decidability which is what the already added answers focus on)? $\endgroup$ – Nikos M. Jun 5 '14 at 21:17
  • $\begingroup$ I take it you consider the question to be poorly formulated? (You're probably right, feel free to down vote it.) Would it have been better to substitute 'aggressive' with 'complete'? $\endgroup$ – Christian Jun 6 '14 at 20:44

I don't understand Swift's typing system yet, so I can only speculate, but I imagine that it's for the same reason that Scala doesn't have full type inference: nobody knows how to do it in a pragmatically viable way. The combination of parametric polymorphism and subtyping is deadly from the point of view of algorithmic complexity.

  • $\begingroup$ "nobody knows how to do it in a pragmatically viable way" - Do you have a source where I can read up about this? I'd like to learn more. $\endgroup$ – Christian Jun 4 '14 at 14:51
  • 5
    $\begingroup$ @Christian Scala's typing system, like Haskell's, C# and others, is undeciable, see here or here. However, this theoretical undecidability does not bother us in Haskell, because it crops up only for artificial programs. Maybe there is a sufficiently fast full type-inference algorithm for Scala with such a property. Odersky says something to this effect here. $\endgroup$ – Martin Berger Jun 4 '14 at 14:58
  • $\begingroup$ PS The Odersky quote is in the comments to the article I link to. $\endgroup$ – Martin Berger Jun 5 '14 at 7:59
  • $\begingroup$ If it's not possible in a pragmatically viable way for the compiler, what chance does the developer have to figure out the type? $\endgroup$ – gnasher729 Oct 20 '18 at 12:11

I must admit I don't know Swift yet, but here are my thoughts. Putting some type annotations in here and there really helps produce better type error messages. Return types and arguments are a great checkpoint that'd use for this. Given a type inconsistency in a function application, a full type inference system doesn't know if you messed up the argument or the return value; it just sees that they are incompatible. By annotating, it we can basically tell the user they are (1) returning a value of the wrong type, or (2) taking a parameter of the wrong type. (The same could be said for an inferred assignment, but we want the inference to do some of the work, just not all of it.)

I am getting this from extensive Haskell experience, which performs full inference. Function signatures are generally the smart place to add a type annotations; then let the type system do the rest within the function.

Other benefits:

  • It improves program comprehension and readability. Seeing the type next to the function helps us understand it quicker. We don't want to have read code and do type inference ourselves to understand what it returns.

  • Extra type constraints speed up the inference process. I'm not totally convinced anyone cares about this too much. Maybe Apple does in their case.


There are situations in Swift already where compile times are slow because of type inference, so being more aggressive might (will) make this worse.

Type inference needs balancing. It helps you not having to figure out a type when you don’t care (C++ iterators are an example). It helps you using identical source code for different types. It can lead to hard-to-find bugs. That needs balancing, and then there are compilation times.

And I like looking at the first line of a function and figuring it out, without having to read the code.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.