I think opt-in is optimal to avoid any breakage. E.g. if we had a feature of declaring a type parameter “=Other” that just unifies with another existing type parameter, we could changer Into to be defined as
pub trait Into<T> {
fn into<=T>(self) -> T;
}
(I don't really care about the precise syntax, and a MVP might as well just cover the case of supporting nothing but a trait’s parameter being repeated on a trait item.)
The functionality of this would be that into gains an optional type parameter and if this parameter is explicitly given, the given type is simply unified with the parameter in question. If nothing is explicitly given, then it’s the same as if _ was given, which contributes nothing to restricting or disambiguating the parameter in question.
Edit: Also, it would need to be allowed to not repeat the declaration of such a =T parameter in a trait implementation for Into.
E.g. the most complex case of unification would also support fun cases like
let x: (bool, _, _) = Into::<(_, i32, _)>::into::<(_, _, f64)>(foo);
and the compiler would combine all the type information to deduce that the target type is (bool, i32, f64); though the more common use-case of course would be of the form
let x = foo.into::<(bool, i32, f64)>();