-
Notifications
You must be signed in to change notification settings - Fork 13.4k
Document why Any is not an unsafe trait #67519
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
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.
r=me with nits
r? @Centril |
9342629
to
6878913
Compare
@bors r=Centril |
📌 Commit 6878913 has been approved by |
🌲 The tree is currently closed for pull requests below priority 100, this pull request will be tested once the tree is reopened |
Document why Any is not an unsafe trait The added documentation is not public (i.e., not in a doc comment) but that seems appropriate for this sort of low-level detail. Fixes rust-lang#62303
Document why Any is not an unsafe trait The added documentation is not public (i.e., not in a doc comment) but that seems appropriate for this sort of low-level detail. Fixes rust-lang#62303
Document why Any is not an unsafe trait The added documentation is not public (i.e., not in a doc comment) but that seems appropriate for this sort of low-level detail. Fixes rust-lang#62303
Rollup of 8 pull requests Successful merges: - #66877 (Add simpler entry points to const eval for common usages.) - #67299 (Add `ImmTy::try_from_(u)int` methods) - #67487 (Rustdoc mutability removal) - #67499 (Misc MIR building cleanups) - #67506 (Remove iter_private.rs) - #67508 (Fix typo in path parser name) - #67519 (Document why Any is not an unsafe trait) - #67525 (Utilize rust-lang/rust commit hashes in toolstate) Failed merges: r? @ghost
// We could plausibly make this trait unsafe -- it would not cause breakage, | ||
// since we control all the implementations -- but we choose not to as that's | ||
// both not really necessary and may confuse users about the distinction of | ||
// unsafe traits and unsafe methods (i.e., `type_id` would still be safe to call, | ||
// but we would likely want to indicate as such in documentation). |
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.
To the contrary, I think making this trait unsafe will help explain the difference between unsafe traits and unsafe methods as it gives a fairly simple example for such a combination. Anyone writing unsafe code should be comfortable with that distinction.
Not a big deal, though.
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.
Yeah, fwiw, I had the same thought while reading this, but ultimately kept quiet cause "not a big deal". ^^
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.
I mostly just didn't want to wait for crater, but since people seem on board with unsafe here I might reconsider. I do think it's not a bad example.
The added documentation is not public (i.e., not in a doc comment) but that seems appropriate for this sort of low-level detail.
Fixes #62303