Auto implementing foreign trait for all private trait implementors

1

I've got a quick question. Why isn't

impl<T:PrivateTrait> TraitFromStdLib for T

allowed. I get why it isn't allowed for traits beyond your control. But there really isn't any weird edge case behaviour with allowing this (specifically for traits private within a crate) is there?

I couldn't come up with an counter example (and there shouldn't be, as all implementors of PrivateTrait are local to the crate and thus respect the rules of implementing foreign traits). It would be nice if Rust supported this natively, without have to write a lot of auto impl macros.

2

The standard library could, for example, add a impl<T> TraitFromStdLib for T implementation in a future release, which would conflict with your implementation. The orphan rules prevents this from happening.

1 Like
3

It seems silly now, I get your example.
However, isn't this just a "breaking change" related to the std lib (or whatever crate). Like it doesn't matter if you implement the foreign traits on your structs yourself or if its done automatically. Both are allowed by Rust's orphan rules. And will break if a extern crate decides to produce a conflicting implementation.

So I still don't get why one wouldn't want

impl<T:PrivateTrait> TraitFromStdLib for T

To be possible in Rust.

4

I think because 2 or more unrelated crates could do that, then implement their own private trait for the same std type, and that's exactly what the orphan rule prevents (both crates cannot be in the same project)

e.g.:

// crate A
trait PrivateA {}
impl<T:PrivateA> Iterator for T { ... }
impl PrivateA for u32 {}

// crate B
trait PrivateB {}
impl<T:PrivateB> Iterator for T { ... }
impl PrivateB for u32 {}

now u32 implements Iterator twice

4 Likes
5

How so?

trait CollatzNext {
    fn next(self) -> Self;
}

// Implements private trait for a foreign type.
impl CollatzNext for usize {
    fn next(self) -> Self {
        if self % 2 == 0 {
            self / 2
        } else {
            self * 3 + 1
        }
    }
}

fn main() {
    let i = (5_usize).next();
    println!("{i}");
}
6

I too have occasionally wanted a blanket implementation with some kind of T: LocalToThisCrate bound. But we currently don't even have a way to seal a trait (enusring all implementations are in the current crate) that's recognized by coherence.

The tool we do have for reducing the boiler plate of a bunch of implementations for local types is macros.

2 Likes
7

Thank you for your example, that use just slipped my mind.

So what we actually need in Rust is some kind of "sealed trait" or way to limit traits such that they can only be implemented by the same crate. That would allow blanket impls on foreign traits. This is the RFC working on that, right?

8

Stabilizing that RFC would create a syntax for the existing sealed trait pattern, but doesn't effect coherence. Coherence was mentioned as a future possibility.

1 Like