Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

abgruszecki started this conversation inCC experiment
Discussion options

Currently CC experiment allows types likeList[{*} Proc], with my favorite aliastype 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 likeList could be used to leak scoped capabilities if we can use{*} Proc as its elements. Similarly, a mutable collection likeListBuffer[{*} 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

You must be logged in to vote

Replies: 1 comment 1 reply

Comment options

I think going tounsafeCap is not immediatelyy appealing.

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

typeProc= {*} ()->Unitvalxs:List[Proc]=???valx= 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.

You must be logged in to vote
1 reply
@abgruszecki
Comment options

I think it might make sense to try and stick with a magic import for unsafe code. What I like about making types likeList[{*} 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.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Labels
None yet
2 participants
@abgruszecki@odersky

[8]ページ先頭

©2009-2025 Movatter.jp