CODEWITHSUNDEEP
scalatraitstype-inference
Gonzalez
Gonzalez

Reputation: 711

Why Scala doesn't deduce trait type parameters?

trait foo[F] {
  def test: F
}

class ah extends foo[(Int,Int) => Int] {
  def test = (i: Int,j: Int) => i+j
}

So the question is, why Scala known to be so smart about types cannot just deduce type (Int,Int) => Int from the type of test asking me instead to specify it? Or It is still possible? Or maybe this is backed by some thoughts that I don't have in mind.

Upvotes: 3

Views: 776

Answers (2)

Owen
Owen

Reputation: 39356

For you particular example, inferring type parameters based on inheritance can be ambiguous:

trait A
trait B extends A

trait Foo[T] {
    val x: T
}

trait Bar extends Foo[?] {
    val x: B
}

The type that could go in the ? could be either A or B. This is a general example of where Scala will not infer types that could be ambiguous.

Now, you are correct to observe that there is a similarity between 

class Foo[T](x: T)

and 

trait Foo[T] { x: T }

I have seen work by some into possibly generalizing the similarity (but I can't seem to find it right now). That could, in theory, allow type inference of type parameters based on a member. But I don't know if it will ever get to that point.

Upvotes: 1

Jörg W Mittag
Jörg W Mittag

Reputation: 369420

Your question is basically "why does Scala have only local type inference" or equivalently "why does Scala not have non-local type inference". And the answer is: because the designers don't want to.

There are several reasons for this. One reason is that the most reasonable alternative to local type inference is global type inference, but that's impossible in Scala: Scala has separate compilation and modular type checking, so there simply is no point in time where the compiler has a global view of the entire program. In fact, Scala has dynamic code loading, which means that at compile time the entire code doesn't even need to exist yet! Global type inference is simply impossible in Scala. The best we could do is "whole-compilation-unit type inference", but that is undesirable, too: it would mean that whether or not you need type annotations depends on whether or not you compile your code in multiple units or just one.

Another important reason is that type annotations at module boundaries serve as a double-check, kind of like double-entry book keeping for types. Note that even in languages with global type inference like Haskell, it is strongly recommended to put type annotations on module boundaries and public interfaces.

A third reason is that global type inference can sometimes lead to confusing error messages, when instead of the type checker failing at a type annotation, the type inferencer happily chugs along inferring increasingly non-sensical types, until it finally gives up at a location far away from the actual error (which might just be a simple typo) with a type error that is only tangentially related to the original types at the error site. This can sometimes happen in Haskell, for example. The Scala designers value helpful error messages so much that they are willing to sacrifice language features unless they can figure out how to implement them with good error messages. (Note that even with Scala's very limited type inference, you can get such "helpful" messages as "expected Foo got Product with Serializable".)

However, what Scala's local type inference can do in this example, is to work in the other direction, and infer the parameter types of the anonymous function from the return type of test:

trait foo[F] {
  def test: F
}

class ah extends foo[(Int, Int) ⇒ Int] {
  def test = (i, j) ⇒ i + j
}

(new ah) test(2, 3) //=> 5

Upvotes: 7

Related Questions