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
Prevent opaque types leaking from transparent inline methods
Before this PR, every transparent inline call returning an opaque type
would actually be typed with an intersection type `DECLARED & ACTUAL`,
where `DECLARED` was the declared return type of the transparent method,
and `ACTUAL` was the type actually returned in the expansion, with every
opaque type alias then dealiased. There was no way to guard against this
dealiasing. With the changes in this PR, users are now able to manually
ensure that they receive the types they want, although they might have
to manually annotate the returned type inside of the transparent inline
method body (as described in the added documentation section).
The previous dealiasing was caused by the proxy mechanism in inlining,
which would effectively deals every opaque type, that is transparent
from the perspective of the original method declaration. Now, we try to
map the results of the transparent inline back to the original (opaque)
types.
However all of this is only true for the outermost transparent inline
method calls. Nested calls will not be affected by this change. This is
because the type checker in the original context of the method will see
the opaque type as transparent (so it will type the rest of the method
according to that), and that typing must still hold after inlining the
method e.g.:
```
object Time:
opaque type Time = String
transparent inline makeTime(): Time = "1h"
transparent inline listTime(): List[Time] = List[String](makeTime())
// mapping the results of makeTime() back into opaque types outside
// of the scope of Time will cause an inlining compilation error
// (which we are generally trying to avoid, and which would be
// considered a bug in the compiler).
```
This might cause the aliased type to still leak in a manner that may
feel unexpected. In the above example, even if the List does not have
an explicit type parameter, the type inference will still decide on
`String`, causing any call to listTime to leak that type. This is also
touched upon in the added docs.
This PR might cause some source/library incompatibilities connected to
the changed returned types (but I doubt it’s many, considering the
additional required effort of ignoring type inference if we want the
outputted type to be different).
Copy file name to clipboardExpand all lines: docs/_docs/reference/other-new-features/opaques-details.md
+39Lines changed: 39 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -109,6 +109,45 @@ object obj:
109
109
```
110
110
The opaque type alias `A` is transparent in its scope, which includes the definition of `x`, but not the definitions of `obj` and `y`.
111
111
112
+
## Opaque Types in Transparent Inline Methods
113
+
114
+
Additional care is required if an opaque type is returned from a transparent inline method, located inside a context where that opaque type is defined.
115
+
Since the typechecking and type inference of the body of the method is done from the perspective of that context, the returned types might contain dealiased opaque types. Generally, this means that calls to those transparent methods will return a `DECLARED & ACTUAL`, where `DECLARED` is the return type defined in the method declaration, and `ACTUAL` is the type returned after the inlining, which might include dealiased opaque types.
116
+
117
+
API designers can ensure that the correct type is returned by explicitly annotating it inside of the method body with `: ExpectedType` or by explicitly passing type parameters to the method being returned. Explicitly annotating like this will help for the outermost transparent inline method calls, but will not affect the nested calls, as, from the perspective of the new context into which we are inlining, those might still have to be dealiased to avoid compilation errors:
118
+
119
+
```scala
120
+
objectTime:
121
+
opaquetypeTime=String
122
+
opaquetypeSeconds<:Time=String
123
+
124
+
// opaque type aliases have to be dealiased in nested calls,
125
+
// otherwise the resulting program might not be typed correctly
126
+
// in the below methods this will be typed as Seconds & String despite
127
+
// the explicit type declaration
128
+
transparentinlinedefsec(n: Double):Seconds=
129
+
s"${n}s":Seconds
130
+
131
+
transparentinlinedeftestInference():List[Time] =
132
+
List(sec(5)) // infers List[String] and returns List[Time] & List[String], not List[Seconds]
0 commit comments