Opt-in implementations and alternative solutions


#1

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.


#2

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. :wink:


#3

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.


#4

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”?


#5

I’ve only discussed it with Sergio for now.