-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Semver: Note that it is not a breaking change to make an unsafe
function safe
#11200
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (or someone else) soon. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
I think at some point in the future, we'll also want to cover unsafe traits/impls.
Sorry for the delay, I think I've resolved your concerns now. I agree about traits, and also wanted to add a section about |
Semver: Note that it is not a breaking change to make an unsafe function safe This is a repost of #11200 with some requested edits made. This makes it clear that it is a minor change due to our policy that triggering new lints is not a breaking change. I also simplified it by not repeating what constitutes a breaking change for a trait definition, and instead link to the rule that specifies no signature changes are allowed.
☔ The latest upstream changes (presumably #12116) made this pull request unmergeable. Please resolve the merge conflicts. |
Closing as merged in #12116. |
I asked this a while ago on the users forum, and thought it would be nice to have in the main documentation.
I marked this as a "minor" change because the only way it breaks is if the user is opting out of Rust's stability guarantees in general. But happy to make it "possibly breaking" if that suits you?