Alternative scheme for cc encapsulation

[odersky]

Starting with a design document for exploring possible alternatives to the current encapsulation scheme in cc, this PR
implements a different, simpler scheme from what we had before.

• All type variables are treated as sealed, no explicit modifier necessary
• Local roots are dropped as well
• To regain expressiveness, we introduce reach capabilities x*

[odersky]

We went from 104 uses of @uncheckedCaptures in stdlib collections to 1 (a low-level class inside LazyListIterable).

[Linyxus]

The commit I just pushed is a reclassification of tests mentioned in #18899.

There are rough edges still: we could have made i15749a work, but we could not right now due to a expressiveness limitation of the current implementation.

To recap, i15749a previously stops working because it instantiates a type parameter with an instance containing cap:

def forceWrapper[A](mx: Wrapper[Unit ->{cap} A]): Wrapper[A] =
  strictMap[Unit ->{cap} A, A](mx)(t => force[A](t))  // error

but we needn't have done that as we could instead instantiate the type parameter with Unit ->{mx*} A. In other words, we refine the cap to a reach capability.

That requires typing mx as Wrapper[() ->{mx*} A], which, however, is not possible due to a limitation in the implementation. To see why, Wrapper[T] church-encodes a simple wrapper around T, being expanded to [X] -> (op: T => X) -> X. The problem then arise: it contains a cap at contra-variant occurance! This stops the refinement rule from taking effect.

Such expressiveness limitation extends to church-encoding-like patterns in general, where a church-encoded datatype takes an impure operation to act on the encapsulated data. Another example on church-encoded pairs:

trait IO

type Pair[+T, +U] = [R] -> (op: (T, U) => R) -> R
def cons[T, U](a: T, b: U): Pair[T, U] = [R] => op => op(a, b)
def car[T, U](p: Pair[T, U]): T = p((a, b) => a)
def cdr[T, U](p: Pair[T, U]): U = p((a, b) => b)

def foo(p: Pair[IO^, IO^]): Unit =
  var x: IO^{p*} = null
  x = car[IO^{p*}, IO^{p*}](p)  // error

Neither could it be compiled as the compiler currently cannot type p as Pair[IO^{p*}, IO^{p*}].

There is hope: these cases can actually be detected. For a type like [R] -> (op: (IO^{cap}, IO^{cap}) => R) -> R (which is dealiased from Pair[IO^, IO^]), although there are caps in covariant occurrences, the two covariant caps have no means of referring to these flow-in capabilities, so it is still safe to refine the covariant caps to reach capabilities.

[odersky]

Very nice analysis!

[odersky]

@Linyxus Should we merge this now and work on the improvements in separate PRs?

[Linyxus]

LGTM!