-
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
Automatically implement AsRepr and allow deriving FromRepr for fieldless enums #81642
Automatically implement AsRepr and allow deriving FromRepr for fieldless enums #81642
Conversation
r? @estebank (rust-highfive has picked a reviewer for you, use r? to override) |
There is some discussion of a wider change, to start discouraging or deprecating I also wasn't sure if there was a way to make a derive macro not insta-stable, (particularly where the trait they derive is already in the prelude) - there are few enough derive macros that I'm not sure there's prior art for doing so... |
This comment has been minimized.
This comment has been minimized.
I believe that @rust-lang/lang needs to chime in on this. |
I don't think that this does anything new from a lang perspective. Extremely useful to automate, but nothing that you couldn't do before by yourself. It seems like purely the domain of libs and libs-impl to me. |
It's fair that technically it falls under the purview of @rust-lang/libs, but this might have implications for things that t-lang might have discussed in the past. |
This seems entirely reasonable to me, and quite useful. |
I think this needs a Assuming nobody on @rust-lang/libs objects, I think we should add this once it has a feature gate. |
I'm a bit worried about how generic the name Another thing that is a bit confusing about the name is that you write |
This is a little bike-shed-y, but it feels like Into may not be the best name for this derive. In particular, there are potentially other use cases we may want in the future for Into derives, though not necessarily on enums, and the name as-is is not particularly evocative of the behavior given (unlike the other std derives). Maybe something like "IntoDiscriminant" or similar may be preferable? The disadvantage is that this doesn't match the trait name anymore, which is a departure from the norm, but I at least feel like Into may be confusing as a derive without some added context. (But maybe this is something people will just get used to). Other than this concern I definitely think this is nice, though I admit to wanting the inverse ( |
Als note that this will probably break code using |
That's a reasonable point. I do think there's value in matching the name of the trait, but at the same time, I can imagine having other possible ways to derive What if we don't put this in the prelude, and instead put it in a standard module, so that you can
I think it's reasonable to refer to |
Sure. I'm absolutely not suggesting we call it |
In terms of a name that is not just |
Thanks for the feedback! On naming, I've definitely struggled with the combination of:
I would definitely like to add this too in the future, and perhaps we should work out the derive-names for both of these traits together?
I did not realise this, but it does indeed:
Fantastic! I don't suppose you could point me at an example I can crib off, or some documentation I could read? |
You probably only need to apply a |
What about potentially making one of those a "real" trait? Being able to |
☔ The latest upstream changes (presumably #93028) made this pull request unmergeable. Please resolve the merge conflicts. |
Ping from triage: |
@illicitonion @rustbot label: +S-inactive |
@JohnCSimon maybe you should consider the last comments before closing? In #81642 (comment) it was said to be blocked on work of another rust-lang member. I assume the merge conflicts should be irrelevant to the state of the PR until that is resolved. |
@the8472 - sorry, I missed that comment. :( |
Hello, what's the current status w.r.t. this comment? thanks for an update! |
@illicitonion and I are going to meet in the very near future (early next week?) to discuss possibilities. In essence: I believe there's an edition-boundary opportunity to streamline the semantics of enums that complements the edition-boundary opportunity to fix/remove as-casting. We might also be able to make use of the existing |
@illicitonion any status on this? |
Sorry for the delay in responding! @jswrenn and I met (some time ago!) and discussed plans here, and I suspect this PR isn't going to go anywhere, so I'll close it for now. I do think that as-cast reform would be a great thing to work on in general - https://hackmd.io/i2RG5HzjQrGMCTEfIQjXGg and https://hackmd.io/FejspdTdSX-xaPrcFc5W9w are some collections of thoughts we discussed about possible directions for making as-casts and enum conversion in general more reasonable. |
This auto-impl and derive are only allowed when all of the following are true:
considered what type this enum should be convertable into).
C
).data (because for
enum E { Empty() }
,E::Empty as isize
convertsthe address of the function pointer, rather than the discriminant).
values (i.e.
enum E { Empty{} }
) for consistency.Currently this tends to be done using
as
, which has two flaws:repr(u64)
enum, andyou write
value as u8
(perhaps because the repr changed), you getno warning or error that truncation may occur.
From
orInto
.Other types, such as primitive numeric types, support both
as
castsand
From
/Into
conversions, so making this trivial for primitiveenums too seems reasonable.
There are a number of crates which provide macros to provide this
implementation, as well as
TryFrom
implementations. The advantages ofusing infallible conversions, rather than possibly-truncating ones feels
like it warrants a place in
std
.