Open joroKr21 opened 7 years ago
Somewhat related to https://github.com/scala/bug/issues/9770.
@milessabin I don't know about that. But here is how to reproduce inconsistencies in the subtype relation involving type variables:
import scala.reflect.runtime
val universe = runtime.universe.asInstanceOf[runtime.JavaUniverse]
import universe._
val tvar = TypeVar(symbolOf[Set[Any]].typeParams.head)
val struct = typeOf[{ def i: Int }]
val pat = refinedType(tvar :: typeOf[Serializable] :: Nil, NoSymbol)
val tpe = refinedType(struct :: typeOf[Serializable] :: Nil, NoSymbol)
println(tvar =:= struct) // true
println(tvar.constr) // _= AnyRef{def i: Int}
println(tpe =:= pat) // true
println(tpe <:< pat) // true
println(pat <:< tpe) // false
println(pat <:< struct) // false
println(tvar <:< struct) // true
println(tvar.member(TermName("i"))) // <none>
println(tvar.inst.member(TermName("i"))) // method i
Further minimization:
object Test {
type Parent
type Scope = { val x: Int }
implicit def refined[A]: Parent with A = ???
implicitly[Parent with Int] // ok
implicitly[Parent with Scope] // missing
}
A leaky abstraction:
?A <:< Scope
and Parent with ?A <:< Parent with Int
,
but not Parent with ?A <:< Parent with Scope
Below are a few examples involving type aliases and refinement types that show how among several equivalent types, some can be resolved implicitly while others cannot.
I looked more closely into (1).
-Xlog-implicits
reports:Further debugging reveals that at some point implicit resolution checks if the types below are compatible:
Strangely enough though:
Intuitively I would expect
A =:= B
to implyA <:< B
. But I'm not sure what role type variables play here.Scala version: 2.12.3 Java version: Oracle 1.8.0_144