Should we be able to put root capability in type parameters of classes?

[abgruszecki]

Currently CC experiment allows types like List[{*} Proc], with my favorite alias type Proc = Unit => Unit. It seems to me such types should be rejected as ill-formed. The basic argument is that according to the formalism, all elements of such a list should be in an unopenable box. Since we don't have boxes in the surface syntax, the most reasonable thing to do seems to be simply forbidding such types.

Even an immutable collection like List could be used to leak scoped capabilities if we can use {*} Proc as its elements. Similarly, a mutable collection like ListBuffer[{*} Proc] could be easily used to leak a scoped capability and use it outside of its scope.

However, forbidding such types rules out the most natural way to migrate existing code to capture checking, i.e. simply putting {*} as the c.s. of every type. If we are concerned about this, perhaps we should introduce an annotation like @unsafeCap that could be used to allow such types, as in: List[@unsafeCap {*} Proc]?

/cc @odersky

[odersky]

I think going to unsafeCap is not immediatelyy appealing.

List[{*} Proc] is not bad per se, as long as you cannot pull out a value of type Proc. And you can't:

type Proc = {*} () -> Unit
val xs: List[Proc] = ???
val x = xs.head

gives

5 |val x = xs.head
  |        ^^^^^^^
  |The expression's type {*} {*} () -> Unit is not allowed to capture the root capability `*`.
  |This usually means that a capability persists longer than its allowed lifetime.

Now it's a separate question whether we should allow the formation of values of this type if there's not
much we can do with them. But there are other contenders to fix this. In particular, I am thinking of a magic
import for unsafe code that would let us unbox such things.

[abgruszecki]

I think it might make sense to try and stick with a magic import for unsafe code. What I like about making types like List[{*} Proc] ill-formed is that an error would be emitted where the mistake in code was made. With the magic import approach, if I define a function that returns a list of impure procs, I only find out there's a problem if I try to use it.

With that being said, I think we need to be careful not to blow our "strangeness budget" (in the Rust sense). Discussing how the student supervised by Ondrej and Toli could show us how much strangeness we have spent already; my feeling so far is that it's not a small amount.