When we release some traits, due to lack of consideration, the structure may change in the future. In this case, a break change will occur, and we usually need to make it inherit a private trait to prevent other users from implementing it. I think it is necessary to give users a prompt before that, just like # [deprecated], Next, when a user tries to implement it, compiler give out a warning
This has been accepted by an RFC. It's a hard error, not a warning.
before change it, It is better to give users a prompt.
Please read the RFC. It answers a number of questions you likely have.
I think OP might be suggesting some kind of "user implementations on this trait are deprecated" annotation, to facilitate eventually turning a trait sealed in a next major version of their crate - or generally to mark a trait as "this was never intended to be user-implementable". The intended effect would be a warning when the user tries to implement the trait. Note "sealing" vs "sealed".
2 Likes
Yeah
Sounds like something that could be a more general attribute ("going to break this soon even though it's not deprecated").
- Visibility changes
- Meant to make this
non_exhaustive - Taking away a visible field or variant
- Need to change some variance, auto trait, or other leakage
- Removing a default trait method body
- Changing a blanket implementation
- Etc
Incidentally, feature requests that are just thrown out there and not championed rarely go anywhere.
5 Likes
mybe, the name should be change to #[refuse_impl].
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.