Instead of specializing via "default" impls, why not reverse it to specialize by "specialized" impls?

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

Your proposal seems like an even more stripped fown version of min_specialization, except you're missing the requirement to not mention 'static (which makes your proposal unsound).

Regarding the fact that you mark the specializing impl rather than the specialized one, I don't think this brings anything new except the fact that now every normal impl becomes specializable, which I don't think is desiderable.


RFC 1210 likened it to C++ virtual, explicitly allowing the implementation to be overridden.

That answers my question more than anything else - the lack of `'static' inclusion makes this unsound I suppose

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.