I could possibly create a wrapper class/type that coerced the type to be
invariant, for example if I had a wrapper class C[+T].
C[+T](...) {
type B <: T
val innerObj: EitherT[F, A, B]
}
Something like the above could work, right? But I was hoping for a cleaner
solution -- one that didn't require an entirely new class.
On Monday, October 24, 2016 at 3:47:10 AM UTC-7, Stephen Compall wrote:
>
> On October 23, 2016 11:09:16 PM EDT, ace_coder <[email protected]
> <javascript:>> wrote:
> >How do I constrain a covariant type to invariant type so that I can
> >pass it
> >as a type parameter to EitherT?
> >
> >Something of the form:
> >
> >type Method[+T] = EitherT[F, Int, T] // Error: Usage of
> >covariant
> >type in invariant position.
>
> Method can only be defined as Method[T] here. Technically, EitherT[F, Int,
> _ <: T] has the semantics you want and T in covariant position (one
> implication of the covariance of any Cv[+A] is that for all T, Cv[T] = Cv[_
> <: T]), but scalac isn't great at inferring its usage, never mind implicit
> conversions from it.
>
> Covariant type constructors widen to invariant, but not vice versa, and
> the invariance of EitherT is deliberate; see
> https://failex.blogspot.com/2016/09/the-missing-diamond-of-scala-variance.html
>
> for explanation.
>
>
>
>
> --
> Stephen Compall
> If anyone in the MSA is online, you should watch this flythrough.
>
--
You received this message because you are subscribed to the Google Groups
"scalaz" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/scalaz.
For more options, visit https://groups.google.com/d/optout.
