My memory is bad but I’m pretty sure there have already been some discussions (and perhaps rfcs) about opt-in implementations. The fact is this feature have certainly received other names. Consequently I cannot find very relevant information when looking in the past posts/rfcs using my own terminology.
What I mean by “opt-in implementations” would be the possibility to create an implementation I of a trait X for a type Y outside both the crates of X and Y but with the additional constraint one would have to explicitly opt-in this implementation where needed. I believe one of the major reproaches was it would allow a category of subtle bugs (for example creating some code where a single piece of data is modified by two incompatible implementations of the same trait). I would like to plunge back into these discussions. Does that ring a bell?
More generally is there currently any consensus on the best solution to solve the issue described above? If you want to use type Y and you need an implementation of trait X for Y but X and Y come from two completely independent crates you don’t own, what are your options? I suppose newtypes are a possibility but they imply a certain amount of boilerplate.
What you describe sounds a bit like named impls, which have to be imported before they can be used. It was before I got into Rust, so don’t quote me on this, but I think this feature existed in pre-1.0 Rust and got removed because there were some sort of issues with them.
There are moves to get named impls into Rust (see here and here), but I haven’t heard from them in a while. They might need some help being pushed along by a motivated party.
I won’t continue with that because it is decidedly unsound as @withoutboats showed. Crate groups might be a better idea where a crate X can say that it is always developed together with crate Y. I discussed this with Sergio Benitez a bit.
Thanks @troiganto. Named implementations were definitely the appropriate name. I suppose @withoutboats's message here confirms newtypes are indeed the way to go (and this makes delegation even more urgent).
Crate groups might be a better idea where a crate X can say that it is always developed together with crate Y
@Centril is there any discussions about "crate groups"?
