Change into scheme to be fully type-based
#23014
Conversation
We now make into be just a type alias that the compiler knows about. No syntax changes are necessary.
| ``` | ||
| This inserts the given conversion on the `ys` argument in `xs ++ ys`. It typechecks without a feature warning since the formal parameter of `++` is of type `into[IterableOnce]`, which is also the expected type of `ys`. | ||
|
|
||
| The |
There was a problem hiding this comment.
Looks like this paragraph went astray.
There was a problem hiding this comment.
Thanks. I fixed it.
|
At first glance, I really like this -- it feels like it strikes a nice practical balance, and I suspect I'd use it moderately often. I agree that it's quite flexible, but IMO requiring the |
| Since `into` is a regular type constructor, it can be used anywhere, including in type aliases and type parameters. This gives a lot of flexibility to enable implicit conversions for user-visible types. For instance, the Laminar framework | ||
| defined a type `Modifier` that is commonly used as a parameter type of user-defined methods and that should support implicit conversions into it. Pattern like this can be supported by defining a type alias such as | ||
| ```scala | ||
| type Modifier = into[ModifierClass] |
There was a problem hiding this comment.
allowing abstraction like this seems to lose the benefit of keeping it clear that a method argument might be implicitly converted - perhaps tooling™️ can fix this if scaladoc could track if argument types can be converted to
There was a problem hiding this comment.
Yes, maybe. But it was a concern raised by @sjrd, that it would be too cumbersome to require explicit into in user-defined Laminar functions. We can now address that concern. But we should do it only if there's a clear DSL-like pattern, IMO. Laminar modifiers might meet that requirement, but maybe not many other scenarios do.
There was a problem hiding this comment.
Personally i think this is fine, at least it communicates at the definition of the type that its a target
A new version of the
intoscheme to allow certain implicit conversions without requiring a language import.This is a lot simpler than previous schemes since it makes use of the power of the type system instead of building up a parallel structure based on modifiers. It is also considerably more flexible than the previous scheme. One open question might be whether it's too flexible.