开发者

Type Members and Covariance

开发者 https://www.devze.com 2023-02-17 11:25 出处:网络
I guess, \"type variance annotations\" (+ and -) cannot be applied to \"type members\". In order to explain it to myself I considered the following example

I guess, "type variance annotations" (+ and -) cannot be applied to "type members". In order to explain it to myself I considered the following example

abstract class Box {type T; val element: T}

Now if I want to create class StringBox I have to extend Box:

class StringBox extends Box { type T = String; override val element = ""}

So I can say that Box is naturally covariant in 开发者_开发百科type T. In other words, the classes with type members are covariant in those types.

Does it make sense ?

How would you describe the relationship between type members and type variance ?


Box is invariant in its type T, but that doesn't mean there's nothing to see.

abstract class Box {
  type T
  def get: T
}
type InvariantBox = Box { type T = AnyRef }
type SortofCovariantBox = Box { type T <: AnyRef }

What alters the variance situation is the degree to which the type is exposed and the manner it is done. Abstract types are more opaque. But you should play with these issues in the repl, it's quite interesting.

# get a nightly build, and you need -Ydependent-method-types
% scala29 -Ydependent-method-types

abstract class Box {
  type T
  def get: T
}
type InvariantBox = Box { type T = AnyRef }
type SortofCovariantBox = Box { type T <: AnyRef }

// what type is inferred for f? why?
def f(x1: SortofCovariantBox, x2: InvariantBox) = List(x1, x2)

// how about this?
def g[U](x1: Box { type T <: U}, x2: Box { type T >: U}) = List(x1.get, x2.get)

And etc.

0

精彩评论

暂无评论...
验证码 换一张
取 消