This is much less of a suggestion and more of a question as to why the following wouldn't work. It seems pretty clear that "default" impls will not be sound without an extremely large number of confusing conditions, which in my mind makes it pretty much dead in the water. But "default" doesn't necessarily do what I want: give me a generic default implementation and the ability to override a trait impl with a specialized impl for certain types. With this in mind, I think that there is a way to make this sound with specialized impls rather than default ones. The idea is that you can specify a trait implementation as specialized. A specialized impls can have no type parameters. Specialized impls cannot conflict with each other. If a type satisfies a trait, you can linearly search through the specialized impls to see if one applies.
I think this is valid? But I must be overlooking something. This, to me, fulfills what I really want out of specialization which is the ability to do something like the following:
trait FastAdd {
fn add(self, rhs: Self) -> Self;
}
impl<T: Add> FastAdd for T {
fn add(self, rhs: Self) -> Self { ... }
}
specialized impl FastAdd for std::simd::f32x2 { ... }
specialized impl FastAdd for std::simd::f32x4 { ... }
Obviously, specialized is not a keyword and default makes no sense in these contexts. So this would only be possible with a new edition.
It wouldn't be nearly as powerful as specialization as specified in the RFC, but I think it would be possible to make sound