I was looking at this error message in the QotW thread:
note: downstream crates may implement trait `std::clone::Clone` for type `&mut _`
It made me wonder if
impl !Trait would make sense just from a diagnostics and documentation perspective: errors like “the
core crate has promised that
&mut _ will never be Clone”, and a place in rustdoc to, say, explain why
Option doesn’t have a
I would expect it to be semver-compatible to add a new negative impl for a trait you didn’t impl before, but semver-breaking to remove such a promise. The usual coherence restrictions would apply.
It seems like it’d have interesting RFC implications, too: It’d be possible, for example, to RFC that
String will never
impl Termination (though I expect such a thing would be quite rare).
Hmm, the compiler could potentially auto-propagate
!Copy promises, and thus be able to confidently say “this cannot be
Copy, so you must borrow or clone here” instead of "it was moved because it doesn’t implement
Copy" and thus implying that you should try adding that to the type.
(And yes, that might get to coherence or specialization stuff later – see Negative bounds & mutually exclusive traits – but I don’t want to go there now.)
Edit: This diagnostic actually just came up on discord: https://discordapp.com/channels/273534239310479360/273541522815713281/482434062330494977 (“I’ll have to impl a copy trait”).