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/into.md
+24-2Lines changed: 24 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -132,6 +132,28 @@ type Modifier = into[ModifierClass]
132
132
```
133
133
The into-erasure for function parameters also works in aliased types. So a function defining parameters of `Modifier` type can use them internally as if they were from the underlying `ModifierClass`.
134
134
135
+
## Alternative: `into` as a Modifier
136
+
137
+
The `into` scheme discussed so far strikes a nice balance between explicitness and convenience. But migrating to it from Scala 2 implicits does require major changes since possibly a large number of function signatures has to be changed to allow conversions on the arguments. This might ultimately hold back migration to Scala 3 implicits.
138
+
139
+
To facilitate migration, we also introduce an alternative way to specify target types of implicit conversions. We allow `into` as a soft modifier on
140
+
classes and traits. If a class or trait is declared with `into`, then implicit conversions into that class or trait don't need a language import.
Here, the strings `"if"`, `"then"`, and `"else"` are converted to `Keyword` using the given conversion `stringToKeyword`. No feature warning or error is issued since `Keyword` is declared as `into`.
151
+
152
+
The `into`-as-a-modifier scheme is handy in codebases that have a small set of specific types that are intended to be the targets of implicit conversions defined in the same codebase. But it can be easily abused.
153
+
One should restrict the number of `into`-declared types to the absolute minimum. In particular, never make a type `into` to just cater for the
154
+
possibility that someone might want to add an implicit conversion to it.
155
+
156
+
135
157
## Details: Conversion target types
136
158
137
159
The description so far said that conversions are allowed if the target type
@@ -176,8 +198,8 @@ given Conversion[Int, C] = C(_)
176
198
177
199
deff(x: T) = ()
178
200
defg(x: C) = ()
179
-
f("abc") // ok
180
-
g("abc") // error
201
+
f(1) // ok
202
+
g(1) // error
181
203
```
182
204
The call `f("abc")` type-checks since `f`'s parameter type `T` is `into`.
183
205
But the call `g("abc")` does not type-check since `g`'s parameter type `C` is not `into`. It does not matter that `C` extends a trait `T` that is `into`.
0 commit comments