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
It is at times useful to have `transparent` methods that are not
`erased`. For instance, a transparent `unapply` might enable inline
reductions, but we want to also keep it at runtime, because the same
type might be matched at compile-time and at run-time.
This commit decouples `transparent` and `erased` again. `transparent`
does not imply `erased`.
Copy file name to clipboardExpand all lines: docs/docs/typelevel.md
+8-26Lines changed: 8 additions & 26 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -229,34 +229,17 @@ The following rewrite rules are performed when simplifying inlined bodies:
229
229
Dropping a binding might make other bindings redundant. Garbage collection proceeds until no further bindings
230
230
can be dropped.
231
231
232
-
## Restrictions for Transparent and Typelevel Functions
232
+
## Restrictions for Transparent and Erased Functions
233
233
234
234
Transparent methods are effectively final; they may not be overwritten.
235
235
236
-
If a transparent
237
-
method has a toplevel match expression or a toplevel splice `~` on its right-hand side,
238
-
it is classified as a typelevel method that can _only_ be executed at compile time. For typelevel methods two more restrictions apply:
236
+
Transparent methods with an implicit match expression on their right-hand side must in addition be declared `erased`. Erased transparent methods must be always fully applied. In addition, the restrictions on normal erased methods apply, including:
239
237
240
-
1. They must be always fully applied.
241
-
2. They may override other methods only if one of the overridden methods is concrete.
238
+
1. They may not override other methods.
239
+
2. They may not be referred to from a non-erased context.
242
240
243
-
The right hand side of a typelevel method is never invoked by dynamic dispatch. As an example consider a situation like the following:
ys.foreach(f) // expands to the body of List's foreach
256
-
zs.foreach(f) // calls Iterable's foreach
257
-
```
258
-
It follows that an overriding typelevel method should implement exactly the same semantics as the
259
-
method it overrides (but possibly more efficiently).
241
+
**Question:** We currently set `erased` automatically for macros, i.e. methods with a
242
+
right-hand side of the form `~...`. But we require it to be written explicitly for methods that have an implicit match as RHS. Should these situations be treated in the same instead? If yes, which of the two is preferable?
260
243
261
244
## Matching on Types
262
245
@@ -415,7 +398,7 @@ There are some proposals to improve the situation in specific areas, for instanc
415
398
By contrast, the new `implicit match` construct makes implicit search available in a functional context. To solve
416
399
the problem of creating the right set, one would use it as follows:
@@ -426,8 +409,7 @@ Patterns are tried in sequence. The first case with a pattern `x: T` such that a
426
409
of type `T` can be summoned is chosen. The variable `x` is then bound to the implicit value for the remainder of the case. It can in turn be used as an implicit in the right hand side of the case.
427
410
It is an error if one of the tested patterns gives rise to an ambiguous implicit search.
428
411
429
-
Implicit matches can only occur as toplevel match expressions of transparent methods. This ensures that
430
-
all implicit searches are done at compile-time.
412
+
Implicit matches can only occur as toplevel match expressions of methods that are both `erased` and `transparent`. This ensures that all implicit searches are done at compile-time.
0 commit comments