Pre-SIP: Allow fully implicit conversions in Scala 3 with `into`

[lihaoyi]

@odersky

Binary compatibility is not really an issue. Let’s take Laminar’s Modifier as an example. A backwards binary compatible way to upgrade would introduce the alias

type ToModifier = into[Modifier]

and then all methods would use ToModifier instead of Modifier in their parameter types. Or they would use into[Modifier] directly. Either scheme would be binary compatible with the current codebase.

That said, I am not fundamentally opposed to also have into as a modifier. It would certainly alleviate all concerns about migration. It should come with a culture that emphasizes that having many into targets just in case someone needs a conversion is a code smell and that it’s better to use more specific into[...] types in arguments. As long as we can foster that culture I would be OK with it.

I think the problem here is that this type-alias approach is forcing a bad dilemma on libraries who want to adopt it:

1. If you keep the class name the same and add an typealias with a new name, you keep binary compatibility but break source compatibility: now all downstream code has to change to use the typealias instead of the original class name to work

2. If you change the class name but add a typealias with the old class name, you break both binary compatibility and source compatibility: now all downstream code previously compiled against the old class name will stop working unless recompiled, and although method signatures won’t need to be changed, any calls to new MyCls or extends MyCls will be broken as well.

“forcing all libraries using implicit conversions to change and break all downstream code that will all need to be updated and/or recompiled” is simply not an acceptable migration plan. So we need to allow into as a modifier on existing types, traits, and classes, and given there isn’t any fundamental reason not to have it, that seems like the right way out of this dilemma