You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/_docs/reference/experimental/capture-checking/basics.md
+8-4Lines changed: 8 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -219,9 +219,12 @@ This widening is called _avoidance_; it is not specific to capture checking but
219
219
220
220
## Capability Classes
221
221
222
-
Classes like `CanThrow` or `FileSystem` have the property that their values are always intended to be capabilities. We can make this intention explicit and save boilerplate by letting these classes extend the `SharedCapability` class defined in object `cap`.
222
+
Classes like `CanThrow` or `FileSystem` have the property that their values are always intended to be capabilities. We can make this intention explicit and save boilerplate by letting these classes extend the `SharedCapability` class defined in object `caps`.
223
+
224
+
A type extending `SharedCapability` always comes with a capture set. If no capture set is given explicitly, we assume the capture set is `{cap}`.
225
+
226
+
This means we could equivalently express the `FileSystem` and `Logger` classes as follows:
223
227
224
-
The capture set of type extending `SharedCapability` is always `{cap}`. This means we could equivalently express the `FileSystem` and `Logger` classes as follows:
In this version, `FileSystem` is a capability class, which means that the `{cap}` capture set is implied on the parameters of `Logger` and `test`.
240
+
In this version, `FileSystem` is a capability class, which means that the occurrences of `FileSystem` in the types of the parameters of `Logger` and `test` are implicitly expanded to `FileSystem^`. On the other hand, types like `FileSystem^{f}` or
241
+
`FileSystem^{}` are kept as written.
238
242
239
-
Another, unrelated change in the version of the last example here is that the `FileSystem` capability is now passed as an implicit parameter. It is quite natural to model capabilities with implicit parameters since it greatly reduces the wiring overhead once multiple capabilities are in play.
243
+
Another, unrelated change in the last version of the `Logger` example is that the `FileSystem` capability is now passed as an implicit parameter. It is quite natural to model capabilities with implicit parameters since it greatly reduces the wiring overhead once multiple capabilities are in play.
Copy file name to clipboardExpand all lines: tests/neg-custom-args/captures/boundary.check
+5-6Lines changed: 5 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -2,14 +2,13 @@
2
2
4 | boundary[AnyRef^]:
3
3
5 | l1 ?=> // error // error
4
4
| ^
5
-
|Found: scala.util.boundary.Label[Object^'s1]^
6
-
|Required: scala.util.boundary.Label[Object^²]^³
5
+
|Found: scala.util.boundary.Label[Object^'s1]
6
+
|Required: scala.util.boundary.Label[Object^]^²
7
7
|
8
-
|Note that capability cap cannot be included in outer capture set 's1.
8
+
|Note that capability cap cannot be included in outer capture set 's1.
9
9
|
10
-
|where: ^ refers to a fresh root capability classified as Control created in value local when constructing Capability instance scala.util.boundary.Label[Object^'s1]
11
-
| ^² and cap refer to the universal root capability
12
-
| ^³ refers to a fresh root capability classified as Control in the type of value local
10
+
| where: ^ and cap refer to the universal root capability
11
+
| ^² refers to a fresh root capability classified as Control in the type of value local
0 commit comments