Change workings of experimental into modifier on parameter types
#19673
Conversation
odersky
force-pushed
the
change-into
branch
4 times, most recently
from
53ac2da to
587f3b4
Compare
| @@ -211,6 +211,12 @@ FunArgType ::= Type | |||
| FunArgTypes ::= FunArgType { ‘,’ FunArgType } | |||
| ParamType ::= [‘=>’] ParamValueType | |||
| ParamValueType ::= Type [‘*’] PostfixOp(t, "*") | |||
| | IntoType | |||
| | ‘(’ IntoType ‘)’ ‘*’ PostfixOp(t, "*") | |||
| IntoType ::= [‘into’] IntoTargetType Into(t) | |||
There was a problem hiding this comment.
Having into optional here leads to an ambiguity. If I want to parse a ParamValue and I have Int in front of me, I can choose the Type ['*'] alternative, or the IntoType alternative with this alternative inside.
It seems weird that it is optional here.
There was a problem hiding this comment.
True, but the recognized language the same either way. It's just the AST construction which is ambiguous. But the grammar does not guarantee that anyway.
The into needs to be optional since IntoType is also used after => in IntoTargetTyope.
| @@ -58,24 +58,63 @@ concatAll(List('a'), "bc", Array('d', 'e')) | |||
| ``` | |||
| would apply two _different_ implicit conversions: the conversion from `String` to `Iterable[Char]` gets applied to the second argument and the conversion from `Array[Char]` to `Iterable[Char]` gets applied to the third argument. | |||
|
|
|||
| Note that a vararg parameter type with into modifiers needs to be put in parentheses, as is shown in the example above. This is to make the precedence clear: each element of the argument sequence is converted by itself. | |||
|
|
|||
| ## Retrofitting Scala 2 libraries | |||
There was a problem hiding this comment.
If and when the scala2-library-tasty becomes stable, hopefully we won't need any of this.
There was a problem hiding this comment.
There's also the case where a library wants to cross-build between Scala 2 and 3 and wants to avoid feature warnings for conversions in Scala 3 clients. That library could use @into in its API.
There was a problem hiding this comment.
Such a library wouldn't have Conversions either, though. It would have implicit defs.
There was a problem hiding this comment.
Except if the library also wants to accommodate conversions defined in client code.
intois now a modifier that sits on the precise parameter part where a conversion isallowed.
Hint for reviewers:
into-modifier.md, to see what changed.intoand$intoannotations. These explain what role these annotations play in type checking.