|
[#482] |
project: compiler |
priority: low |
category: feature |
|---|
|
submitter |
assigned to |
status |
date submitted |
|
Burak |
_ |
_ |
2005-11-10 10:26:26.0 |
| subject |
better interaction of views+inference |
| code |
object foo {
case class Bar[A](i:A);
def view[a](i:a):Bar[a] = Bar(i);
def fu[A](b1:Bar[A],b2:Bar[A]):Seq[Bar[A]] = List(b1,b2);
fu(1,"zwei"); // error, sequence treated as Bar[int],Bar[String],Bar[int]
def fa[A](b1:A,b2:A):Seq[A] = List(b1,b2);
fa(1,"zwei"); // ok, sequence treated as Any, Any, Any
}
|
| what happened |
simp.scala:5: no type parameters for method fu of type [A](foo.Bar[A],foo.Bar[A])scala.Seq[foo.Bar[A]] exist so \
that it can be applied to arguments (foo.Bar[scala.Int],foo.Bar[java.lang.String])
--- because ---
argument expression's type is not compatible with formal parameter type;
found : foo.Bar[java.lang.String]
required: foo.Bar[scala.Int]
fu(1,"zwei"); // error, sequence treated as Bar[int],Bar[String],Bar[int]
^
one error found
|
| what expected |
It would be nice if inference and views could interact better in order to allow more well-typed programs. This might require inferring less precise patterns, and is somewhat similar to the constraint solving that has to happen for GADTs. The reasoning might go somehow like
- fu[A] expects Bar[A],Bar[A]
- infer argument 1 yields Bar[A], A in {int, Any}
- infer argument 2 yields Bar[A], A in {String, Any}
- A in arg1 has to be == to A in arg2
- most precise type in intersection is any
- give arg1 and arg2 the types Bar[Any]
The sets {int,Any} and {String,Any} are in fact the supertype closure of a given type. Given that this closure can be an infinite set, it needs to be restricted somehow. |
|
[back to overview] |
