More tweaks to type inference #1482
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,54 @@ | ||
| import reflect.ClassTag | ||
|
|
||
| // The same problems arise in real arrays. | ||
| class A { | ||
|
|
||
| class Array[T] | ||
| object Array { | ||
| def apply[T: ClassTag](xs: T*): Array[T] = ??? | ||
| def apply(x: Int, xs: Int*): Array[Int] = ??? | ||
| } | ||
|
|
||
| // Any of Array[List[Symbol]], List[Array[Symbol]], or List[List[Symbol]] compile. | ||
| var xs: Array[Array[Symbol]] = _ | ||
| var ys: Array[Map[Symbol, Set[Symbol]]] = _ | ||
|
|
||
| //xs = Array(Array()) | ||
| // gives: | ||
| // | ||
| // isApplicableSafe.scala:15: error: type mismatch: | ||
| // found : A.this.Array[Nothing] | ||
| // required: A.this.Array[Symbol] | ||
| // xs = Array(Array()) | ||
| // | ||
| // Here's the sequence of events that leads to this problem: | ||
| // | ||
| // 1. the outer Array.apply is overloaded, so we need to typecheck the inner one | ||
| // without an expected prototype | ||
|
There was a problem hiding this comment. What if instead of giving up when this fails, we tried to re-typecheck the inner call using every possible overload? Of course this would have to be done carefully to avoid ending up like the Swift typechecker which apparently gives up when trying to compile On a more general note, it seems that there is a tension in Scala caused by overloading: on one hand it significantly reduces the power of type inference, on the other hand it makes some APIs much nicer to use. So either we figure out how to get overloading to play well with type inference, or we come up with a more principled alternative to overloading that helps us keep our APIs nice. There was a problem hiding this comment. Yeah, I am very nervous about trying all combinations. That typically leads to blowup in compile times. Then you either become too restrictive and can't even typecheck trivial expressions or your compile times go through the roof. In both cases there's little a programmer can do. |
||
| // | ||
| // 2. The inner Array.apply needs a ClassTag, so we need to instantiate | ||
| // its type variable, and the best instantiation is Nothing. | ||
| // | ||
| // To prevent this, we'd need to do several things: | ||
| // | ||
| // 1. Pass argument types lazily into the isApplicable call in resolveOverloaded, | ||
| // so that we can call constrainResult before any arguments are evaluated. | ||
| // | ||
| // 2. This is still not enough because the result type is initially an IgnoredProto. | ||
| // (because an implicit might have to be inserted around the call, so we cannot | ||
| // automatically assume that the call result is a subtype of the expected type). | ||
| // Hence, we need to somehow create a closure in constrainResult that does the | ||
| // comparison with the real expected result type "on demand". | ||
| // | ||
| // 3. When instantiating a type variable we need to categorize that some instantiations | ||
| // are suspicous (e.g. scalac avoids instantiating to Nothing). In these | ||
| // circumstances we should try to excute the delayed constrainResult closures | ||
| // in order to get a better instance type. | ||
| // | ||
| // Quite a lot of work. It's looking really complicated to fix this. | ||
|
|
||
|
|
||
| ys = Array(Map(), Map()) | ||
|
|
||
| val zs = Array(Map()) | ||
| } | ||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit message of 3664854 explains why merging is needed but this is tricky enough that it should also be explained in a comment here.