Couldn't trait aliases, in theory, be implemented to bypass the orphan rules?

1

I understand why the orphan rules are in place, but in theory, couldn't trait aliases be revised to also allow implementations on them to allow users to, for example, easily derive Serialize and Deserialize on external types?

This may sound bad (and understandably so, since newtypes are always a fine alternative), but let's see:

trait SerializeExt = Serialize;

impl SerializeExt for OnceCell { ... }

You would have to import SerializeExt directly to have Serialize for OnceCell, like any other trait, but would also function like Serialize (so any function taking a type of Serialize can also take SerializeExt). Isn't the entire issue that the orphan rules solve completely done away by this? That is, external crates implementing traits for external types and causing dependency hell.

I could be very wrong though so please tear this whole thing apart :slightly_smiling_face: I'm posting for exactly that

For starters, I could see that this kind of goes against the idea of this being an "alias", considering type aliases can't be implemented on (though this is something I've always dreamed for, even if it's unlikely to ever happen!)

2

No, I can import two unrelated SerializeExt, for example maybe the core functionality of both traits uses it as a supertrait. It could also allow a way of implementing mutually exclusive traits, which has been a blocker for other suggestions to expand coherence.

And there are other cross-crate things that get wonky, like type erasure and downcasting of a type that has different implementations -- or no implementation! -- of a trait, depending on what crate it's in.

On the topic of implementing on aliases more generally, I have no idea where the wind is blowing, but this RFC PR exists.

1 Like
3

Yeah that would be a problem actually, one crate could implement it then another crate could as well, and even if neither actually expose the trait alias it would result in multiple implementations

I suppose it could be possible(?) if you can't pass it like you would the underlying trait but at that point you're basically better off using a newtype