-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Make caps.Capability
non-experimental
#23507
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
We also need to make SharedCapability (and maybe Control) non-experimental, since Label will extend it. |
01849f0
to
72ced26
Compare
72ced26
to
be436ce
Compare
be436ce
to
a402cf3
Compare
library/src/scala/caps/package.scala
Outdated
@@ -24,14 +24,12 @@ import annotation.{experimental, compileTimeOnly, retainsCap} | |||
* | |||
* Capability has exactly two subtraits: Shared and Exclusive. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's at least make the scaladocs with @experimental or mention it, so that people are aware that there is still a scenario that this might be deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tgodzik I think we are ready to commit to that now. That is, if capture checking becomes standard at one time then we plan to have these traits defined. The doc page is waiting to be merged here: https://github.com/scala/scala3/blob/3658d3da98eb0c5ed33c74ec6402562330bf9ed8/docs/_docs/reference/experimental/capture-checking/classifiers.md
If capture checking does not make it into the standard, the whole caps
package would be deprecated and dropped. So in a sense it does not matter which traits are exposed in there.
An alternative would be to bend the rules so that we make boundary.Label
non-experimental even though it would extend experimental traits, which is usually not allowed. I am not sure that would address the concerns with inlining though. @natsukagami can you comment on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's fine I think. I was mostly hoping to mention in some place that this is not something people should use unless they are experimenting with CC
These are all neccessary for boundary.Label
a402cf3
to
0ad0244
Compare
@tgodzik Good point. We should mention that these traits make sense only for capture checking, which is experimental. |
@natsukagami Let's add a note to this effect in the doc comments of all affected traits. |
I updated the doc-comments to mention experimental capture checking on all traits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me now.
* During separation checking, shared capabilities are not taken into account. | ||
*/ | ||
@experimental | ||
trait SharedCapability extends Capability, Classifier | ||
|
||
@experimental |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not remove the experimental from this alias too?
@experimental |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to remove experimental here, and we want to work a bit with it to see whether it is a good idea to have a short alias.
<!-- - **Add capture checking to boundary and NonLocalReturns** - **Add capture-checking test for boundary** - **Patch DropBreaks to correctly detect boundary blocks** - **Add capture checking to CommandLineParser** - **Add capture checking to scala.util** - **Add capture checking to scala.runtime** - **Add capture checking to rest of scala.runtime (except TupledFunctions)** - **Add capture checking to IArray** - **[TODO INVESTIGATE] IArray: `Array[AnyRef^{xs*}]` not working, revert cast** - **Add capture checking to various scala.* base package files** - **[TODO FIX] Temporarily drop upper bound of higher-kinded type `F` in tuple match types** - **Add capture checking to scala.reflect** - **[TODO REMOVE] Add TODO list** - **[TODO EXPLAIN] Add capture checking to Mirror and TupleMirror** - **Add capture checking to scala.caps** - **Add capture checking to compiletime.Ops** - **Add capture checking to stdLibPatches** - **Add capture checking to annotations** - **Attempt to capture-check quotes** - **Track sun.misc.Unsafe in LazyVal implementation** - **Require Conversion to be pure** --> ## List of changes - Capture checking enabled for all files except listed in the next section - `boundary` is now capture-checked, preventing `Label` from being leaked outside of its corresponding `boundary`. Requires #23507. - ` ## Files missing capture checking - [ ] `Tuple.scala`, waiting for #23695 to reach the next base version - [ ] `Mirror.scala`, which requires auto-generated Mirrors to be compatible with extending one of the `caps.Capability` subtraits. Currently the plan is to simply ban case classes. --------- Co-authored-by: Hamza Remmal <hamza@remmal.net>
Closes #22745.
Make
scala.caps.Capability
non-experimental.The
Capability
trait can be used as a marker trait even outside of capture-checking.Only when capture checking is enabled, the trait carries a special meaning, marking each instance a top-level capability.
Other definitions inside the
scala.caps
package (the package is already non-experimental) stays experimentaland can only be used with
-experimental
or with capture-checking enabled (with an import or with the feature flag).