Limiting `upstream crates may add new impl of trait in future versions`

View all comments

Hello,

I've run into this one a few times now when working with generics, and I haven't really found a way to bypass it in most cases.

I completely get why this is here, "be careful, your behaviour may change if you update your crates, it may even stop compiling altogether" seems like a fair thing to warn against.

BUT: most of the time, when this error appears, it's for types that have been stabilised a while ago, and are way more likely never to add new implementations.

Wouldn't it be a good thing to be able to tell Rust "Yes, I know, this might conflict in the future, but with the current version, it's fine, so let me build until there ARE conflicts" ?

Rust's generics through traits and monomorphisation is one of my favourite features, but sometimes, in situations like this, Rust is TOO smart for its own good, and I think there should be ways to temper it.

This would also help with the problems that have been mentioned in the context of specialization and negative reasoning (maybe this could even enable negative reasoning which has the advantage of being more flexible and expressive than the currently selected "default" oriented specialisation), since breaking changes due to new implementations have always been limiting factors for them.

Start by reading issue #2758 and the linked GitHub comments to understand the existing discussion about upstream trait implementations. The issue does not name files or tests; progress would require turning the broad proposal into an agreed design covering future impl conflicts, specialization, and negative reasoning.