-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Decide on semantics for enum -> integer casts on non-Copy enums. #35941
Comments
The safe option is, of course, to execute the drop. However I think that not running makes more sense to me. For one, it would match the semantics of transmute, which is the only other way to get this kind of situation (converting from a type that impls to one that doesn't). Another option, though it would be more breaking than either already mentioned, would be to disallow enum -> int casts where the enum implements |
My original intent when I wrote the conversion code was to execute the drop. That was before |
We discussed this in the @rust-lang/lang meeting. We like the idea of making it an error to coerce an enum to an integer if that enum type supports |
triage: P-medium |
Some mentoring instructions of how I think this could be implemented:
|
Thanks @oli-obk for the detailed approach. I'll take a stab at it if no one is working on it already. |
…ing-drop, r=matthewjasper,nikomatsakis Report error when casting an C-like enum implementing Drop Following approach described in rust-lang#35941
…ing-drop, r=matthewjasper,nikomatsakis Report error when casting an C-like enum implementing Drop Following approach described in rust-lang#35941
…ing-drop, r=matthewjasper,nikomatsakis Report error when casting an C-like enum implementing Drop Following approach described in rust-lang#35941
…ing-drop, r=matthewjasper,nikomatsakis Report error when casting an C-like enum implementing Drop Following approach described in rust-lang#35941
…ing-drop, r=matthewjasper,nikomatsakis Report error when casting an C-like enum implementing Drop Following approach described in rust-lang#35941
Casting an
enum
which does not deriveCopy
to an integer moves atm:This matches the behavior of other coercions/casts, specifically unsizing ones (
Box<T> -> Box<Trait>
).However, one difference arises between old trans and MIR trans, wrt drops:
On stable, old trans will run the destructor exactly once. After #35764, MIR trans doesn't run it at all.
The reason is that the move that borrowck knows about causes the drops in MIR to be statically elided, whereas old trans forgot(?) to drop-fill
e
, resulting in the variable being dropped at end of scope.Should the drop execute or not? IMO it's good to have uniformity between all moving operations.
The text was updated successfully, but these errors were encountered: