Are there disadvantages to return type inference? If yes, what are they?

Question

A lot of statically typed languages, like C++ and C#, have local variable type inference (with the keywords auto and var respectively, I think).

However, I haven't seen many C-derived languages (apart from those mentioned in the comments) implementing compile-time return type inference. I'll describe what I mean by "return type inference" before I ask the question. (I definitely don't mean overloading by return type.)

Consider this code in a hypothetical C#-like language:

private auto SomeMethod(int x)
{
    return 3 * x;
}

It's more than obvious (to humans and to the compiler) that the return type is int (and the compilers can verify it).

The same goes for multiple paths:

private auto SomeOtherMethod(int x)
{
    if(x == 0) return 1;
    else return 3 * x;
}

It's still not ambiguous at all, because there is already an algorithm in said languages to resolve whether two expressions have compatible types:

private auto YetAnotherMethod(int x)
{
    var r = (x == 0) ? 1 : 3 * x;
    return r;
}

Since the algorithm exists and it is already implemented in some form, it's probably not a technical problem in this regard. But still, I haven't seen it anywhere in statically typed languages, which got me thinking about whether there's something bad about it.

---

My question:

• Does return type inference, as a concept, have any disadvantage or subtle pitfall that I'm not seeing? (Apart from readability - I already understand that.)
• Is there some corner case where it would introduce problems or ambiguity to a statically typed language? (By "introduce", I'm referring to issues that local variable type inference doesn't already have.)

Answer 1

yes, there are disadvantages. one you already mentioned: readability. second - the type has to be calculated so it takes time (in turing-complete type systems it may be infinite). but there is also something different - theory of type systems is much more complicated.

let's write a function that takes a list and return its head. what's its type? or function that takes a function, and a parameter applies that and return the result. in many languages you can't declare it. to support this kind of stuff, java introduced generics and it failed miserably. currently it's one of the most hated features of the language because of consistency problems

another thing: returned type may depend on not only the body of the function but also context of the invocation. let's look at haskell (that has best type system i've ever seen) http://learnyouahaskell.com/types-and-typeclasses there is a function called read that takes a string, parse it and return... whatever you need, an int, an array.

so each time a type system is designed, the designer has to choose at which level she wants to stop. dynamic languages decided not to infer types at all, scala decided to do some local inference but not, for example, for overloaded or recursive functions and c++ decided not to infer the result