[#1008] | project: compiler | priority: medium | category: bug | |
---|---|---|---|---|
submitter | assigned to | status | date submitted | |
Burak | Martin | fixed | 2007-03-16 11:47:27.0 | |
subject | implicit + tuple? + overload interaction | |||
code |
trait ov { implicit val foo = new collection.mutable.HashMap[(Int,Int),Int] implicit val bar = new collection.mutable.HashMap[(Int,Char),Int] // ^ if this is commented, error disappears def ValDef(x:Int, y:Int) // if only this is commented, wrong number of arguments def ValDef(x:Int) ValDef(42,7) } |
|||
what happened | tsf-wpa-1-085:~/Documents/svn/scala buraq$ ../fallback.scala/build/quick/bin/scalac -d /tmp /tmp/ov.scala /tmp/ov.scala:8: error: type mismatch; found : (scala.Nothing, scala.Nothing) required: scala.Int Note that implicit conversions are not applicable because they are ambiguous: both value bar in trait ov of type => scala.collection.mutable.HashMap[(scala.Int, scala.Char),scala.Int] and value foo in trait ov of type => scala.collection.mutable.HashMap[(scala.Int, scala.Int),scala.Int] are possible conversion functions from (scala.Nothing, scala.Nothing) to scala.Int ValDef(42,7) ^ one error found |
|||
what expected | compile without error. The compiler gives the impression that it considers both, ValDef(x:Int,y:Int) and ValDef(x:Int) as targets for the call. This is clearly a compiler bug, since ValDef can be called without any conversion. Furthermore, the compiler seems to explore applicability of implicit coercions in order to transform (Int,Int) to a single Int, and reports ambiguity. This is strange because if the first ValDef method is commented out, no such attempt is made (and it's ok, sth like this should never be attempted, IMHO). Finally the error message does not make any sense, because there is no ambiguity, but given that the typechecker is already hopelessly confused here it is probably of no importance. |
|||
[back to overview] |
Martin edited on 2007-03-16 14:36:54.0 |