-
-
Notifications
You must be signed in to change notification settings - Fork 14.7k
Any trait should be unsafe #62303
Copy link
Copy link
Closed
Labels
A-DSTsArea: Dynamically-sized types (DSTs)Area: Dynamically-sized types (DSTs)C-bugCategory: This is a bug.Category: This is a bug.T-langRelevant to the language teamRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-DSTsArea: Dynamically-sized types (DSTs)Area: Dynamically-sized types (DSTs)C-bugCategory: This is a bug.Category: This is a bug.T-langRelevant to the language teamRelevant to the language teamT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Fields
Give feedbackNo fields configured for issues without a type.
What is wrong?
Since
type_id()is stable rust programs rely onAnyto be implemented correctly for rust safety relevant thinks (like downcast).Given the coding guide lines
Anyneeds to be aunsafe-to-implement trait as implementing it wrongly causes unsafety.Is it a problem?
Luckily no on can (currently) implement
Anyper-hand as any implementation conflicts with it's wild card implementations this means:Anyhappen to be correct.Why should we change it?
The std is often used as an example for how thinks are done correctly in rust. If it is unsafe people looking at it would potentially think about why it needs to be unsafe and learn something from it. But if it isn't they might be surprised when there
Anylike trait is leads to unsafe behavior.What if we can't change it?
I think we can, as practically no one can implement any by hand. But if we can't we should at last document that it should be any in it's rust doc.