From the latest core team meeting notes regarding the future of implicit conversions:
There are two questions here, the timetable of introducing warnings and errors, and the longer-term status of
implicit defitself. We may need a fresh round of community input in order to find out how many libraries are still dependent onimplicit def(for real reasons, not just inertia). Seb has proposed considering keepingimplicit def, if it has turned out thatConversionisn’t powerful enough. The warning for Conversion will most likely be merged into 3.10 becoming an error from 3.11.
TLDR; No, Conversion is not powerful enough.
Use-case Coverage
I think there is no disagreement in the community that the old-style implicit def can be too surprising and too powerful without good guardrails, especially the global implicit defs. However, the new Conversion mechanism along with the into modifier currently fails to cover all reasonably safe uses.
Missing new-style inline conversions
Both inline implicit def and transparent inline implicit def have use cases. This where the type information given to Conversion is not enough and we need the actual tree. This mechanism is used in libraries like iron and refined to check the precise source type and fail with a relevant message.
Missing new-style from modifier
into helps only where we own the target type or the definition site. But there are cases where we own the source type and want to be able to implicitly convert to the target type. It is common to have Wrapper[T](t: T) with a conversion Wrapper[T] -> T. I want a from modifier to place on Wrapper so this conversion can be applied everywhere without any redundant flags.
Conversion vs. Extension
It’s important to distinguish between use sites where implicit conversions are meant for converting x: X -> conv(x: X): Y and where they are meant for old-style extensions (x: X).a -> (conv(x: X): Y).a.
The current plan to treat both the same when it comes to deprecation is wrong, IMO. I think we need a separate warning/error deprecation mechanism where old-style extension and old-style conversion is used
Old-style extension deprecation
We need to differentiate between implicit class and implicit def. One of the most surprising behavior of old-style implicits is the extension mechanism manifesting from implicit def. I think this pattern is the first one we should deprecate, separately from implicit class where that intent is clear.
As for deprecating implicit class, I would first want to see if we can still mitigate this issue Relaxed extension methods (SIP 54) are not relaxed enough
Old-style conversion deprecation
Here I think we need to separate the deprecation between places where we own either the target or the source type and between the horrible global implicit conversions and between inline and non-inline conversions. Truly global non-inline implicit conversions - deprecate now. The rest require mitigation with relevant language features like from and inline Conversion (or no deprecation at all if there is no fallback).