Honor @uncheckedVariance in type alias

[scabug]

In akka-stream we use reactive-stream Publisher and Subscriber interfaces, which are implemented in Java. At several places we had to add uncheckedVariance annotation. A suggestion by @retronym was to define those in a type alias instead.

It turns out that the type alias is expanded and the uncheckedVariance annotation is not used.

Discussion and example that illustrates the problem can be found here: akka/akka#15643

[edit] Reproducing the example here:

Indeed, variance validation seems to dealias, which thwarts the attempt to indirect through an unchecked alias.

scala> trait F1[/* - */T, /* + */ R]; import scala.annotation.unchecked._; type VariantF1[-T, +R] = F1[T @uncheckedVariance, R @uncheckedVariance]
defined trait F1
import scala.annotation.unchecked._
defined type alias VariantF1

scala> trait C[+T] { def foo: VariantF1[Any, T] }
<console>:27: error: covariant type T occurs in invariant position in type => VariantF1[Any,T] of method foo
       trait C[+T] { def foo: VariantF1[Any, T] }
                         ^

Contrast with:

scala> trait F1[/* - */T, /* + */ R]; import scala.annotation.unchecked._; trait VariantF1[-T, +R] extends F1[T @uncheckedVariance, R @uncheckedVariance]
defined trait F1
import scala.annotation.unchecked._
defined trait VariantF1

scala> trait C[+T] { def foo: VariantF1[Any, T] }
defined trait C
Or:

scala> trait F1[/* - */T, /* + */ R]; import scala.annotation.unchecked._; trait O { type VariantF1[-T, +R] <: F1[T @uncheckedVariance, R @uncheckedVariance]}; object O extends O
warning: there was one feature warning; re-run with -feature for details
defined trait F1
import scala.annotation.unchecked._
defined trait O
defined object O

scala> trait C[+T] { def foo: O.VariantF1[Any, T] }
defined trait C

I'm not sure whether or not subclassing or using a upper bounded type declaration would work for your use case.

[scabug]

Imported From: https://issues.scala-lang.org/browse/SI-8795?orig=1
Reporter: Patrik Nordwall (patriknw)
Affected Versions: 2.10.4
See #8079

[scabug]

@paulp said:
Duplicate of #8079. Everyone is aware there are a couple thousand open tickets, right? On a purely statistical basis you have to figure that whatever it is you've encountered, there's a good chance some idiot has already gone to all the trouble of isolating and reporting it.

[scabug]

@retronym said:
I don't believe that this is a straight duplicate. Variance checking actively dealiases, even when no as-seen-from's are in play.

[scabug]

@retronym said:
Related discussion: https://groups.google.com/d/msg/scala-language/Ka5AspTOhmw/ZljgmWkigIoJ

[scabug]

@paulp said:
Maybe the progression of #8079 has led to overspecification, but the problem being reported - @uncheckedVariance on a type alias to a java-defined type - is exactly the same.

[scabug]

@paulp said:
Also, the given example works in policy, where I have applied my patch from #8079 but made no other relevant changes.

[scabug]

@paulp said:
See also my last comment in #8071, six months ago.

[scabug]

@retronym said:
You've convinced me, this is a duplicate.

I'll broaden the scope of #8079 to answer the question: do we need to variance validate type aliases RHS both at definition and usage sites to preserve soundness, or is this behaviour a quirk of history.