Change typeapply

[odersky]

Changes to arrive at a more tractable treatment of higher-kinded types.

[smarter]

Does that mean that we cannot refer to X in L ?

[odersky]

Yes

[smarter]

OK, then this should be explicitly disallowed somewhere, currently the following:

class Test {
  type Foo[X] >: List[X]
}

Triggers an assertion: unresolved symbols: type X
On the other hand, couldn't we rewrite type T[X] >: L <: U as type T = [X] -> (_ >: L <: U) or something else to allow this?

[odersky]

That means bounds can be lambdas (and lambdas are complex arrangements of refinements and references). So what was a TypeBounds type now becomes something very complicated. I am afraid to got there. If we had explicit type lambdas as a separate type it would take it under consideration. But then we need also explicit AppliedType types.

[odersky]

Rebased to master

[smarter]

Typo: TypevarsMissContext

[smarter]

The following:

object Test {
  def foo[M[X] <: List[X]](x: M[Int]) = ???
}

gets pretty-printed after frontend as:

package <empty> {
  final lazy module val Test: Test$ = new Test$()
  final module class Test$() extends Object() { this: Test.type => 
    def foo[M <: [] -> <: scala.collection.immutable.List[X0]](x: M[Int]): Nothing = ???
  }
}

The list of type lambda arguments is [] but should be [X0]

[odersky]

@smarter The print problem should be fixed with 1c77b03.

[odersky]

All comments should be addressed now.

[smarter]

I'm looking into why t3152.scala stopped compiling, I'd like to fix this before merging this PR.

[smarter]

adaptIfHK is wrong, it bypasses variance checks and allows this to compile:

class HKCov[M[+_]] {
  def upcast(m: M[Int]): M[Any] = m
}
class Foo[T]
object Test {
  val x: HKCov[Foo] = new HKCov[Foo]
  val fi: Foo[Int] = new Foo[Int]
  val fa: Foo[Any] = x.upcast(fi)
}

The type parameter of Foo is invariant so it shouldn't be possible to pass Foo to HKCov, however adaptIfHK rewrites [X] => Foo[X] into [+X] => Foo[X], this opens a soudness hole.

I've tried simply removing adaptIfHK and nothing seems to break, and even better: tests/pending/pos/t3152.scala now successfully compiles!

Do you have a test case where adaptIfHK is actually needed?

[odersky]

The comment to adaptIfHK gives some clue. It certainly was needed at some point for compileStdLib. To make sure, it would be good to just compile with some of the mutable classes mentioned in the comment. I.e. starting with GenTraversable and ListBuffer and then add a few.

[odersky]

Indeed we need to test whether the variances correspond before doing the adaptation. I.e. if the context requires nonvariant but the argument is covariant OK, in the other direction not.