4

Sorry for non-descriptive title. Typelevel computation are not too common theme in the internet to establish precise terms.

I tried to use typelevel computations and suddenly get spurious errors every here and there. I just could not comprehend why so little difference matters. I managed to forge another concise example:

trait Sample {
  type X
  type DX[I <: X] <: Nothing
  type EX[I <: X] = Nothing
}
type Aux[I] = Sample {type X = I}

type U1 = Aux[Int]#DX[Int] // ok
type U2 = Aux[Int]#EX[Int] // fails

The error message is:

error: type arguments [Int] do not conform to type EX's type parameter bounds [I <: Sample.this.X]
type U2 = Aux[Int]#EX[Int]
                   ^

But the EX and DX had the same type parameter bounds. Why it is right in one case and wrong in the another?

ayvango
  • 5,867
  • 3
  • 34
  • 73
  • I've suffered these sort of issues more than my share. There are *local* workarounds, that most likely will cause (other) issues elsewhere. For example, you can define `EX` as `type EX[I <: X] >: Nothing <: Nothing`, and your code compiles. There are other options, I could expand if there's interest. – Eduardo Pareja Tobes Sep 02 '17 at 16:46
  • I'm highly interested. There are two other questions that are very mysteriously to me: https://stackoverflow.com/questions/45729325/why-certain-recursive-types-fail-to-compile and https://stackoverflow.com/questions/45643135/how-to-define-type-lambda-properly Three errors were enough to defeat me. So I gave up on type level computations and switched to implicits. – ayvango Sep 03 '17 at 20:17
  • But `TList` powered by implicits is very ugly, because it should be naturally described as type constructor and only methods are allowed to have implicits, not type constructors. So I would like to switch back to type level from implicits it it is actually possible – ayvango Sep 03 '17 at 20:18

0 Answers0