RFC: Allow making enums usable in FFI #3803
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
the
T-lang
madsmtm
commented
Apr 21, 2025
kpreid
reviewed
Apr 22, 2025
zachs18
reviewed
Apr 22, 2025
juntyr
reviewed
Apr 22, 2025
clarfonthey
reviewed
Apr 23, 2025
clarfonthey
reviewed
Apr 23, 2025
clarfonthey
reviewed
Apr 23, 2025
bluebear94
reviewed
Apr 24, 2025
madsmtm
added a commit
to madsmtm/wgpu
that referenced
this pull request
Apr 25, 2025
The `metal` crate is currently unsound regarding unknown/future enum variants, see gfx-rs/metal-rs#209 and rust-lang/rfcs#3803. `objc2-metal` fixes this by emitting C enums as a newtype + constants for each variant, but that prevents us from importing the variants/constants. So this commit converts to a pattern that works with that in preparation for the migration.
cwfitzgerald
pushed a commit
to gfx-rs/wgpu
that referenced
this pull request
Apr 25, 2025
The `metal` crate is currently unsound regarding unknown/future enum variants, see gfx-rs/metal-rs#209 and rust-lang/rfcs#3803. `objc2-metal` fixes this by emitting C enums as a newtype + constants for each variant, but that prevents us from importing the variants/constants. So this commit converts to a pattern that works with that in preparation for the migration.
the8472
reviewed
May 4, 2025
More straightforward framing.
|
Thanks for the comments all, and sorry for the delay. I believe I've incorporated your suggestions into the RFC text, but feel free to open a new comment if you disagree! |
madsmtm
changed the title
sinjs
pushed a commit
to sinjs/wgpu
that referenced
this pull request
Jul 22, 2025
The `metal` crate is currently unsound regarding unknown/future enum variants, see gfx-rs/metal-rs#209 and rust-lang/rfcs#3803. `objc2-metal` fixes this by emitting C enums as a newtype + constants for each variant, but that prevents us from importing the variants/constants. So this commit converts to a pattern that works with that in preparation for the migration.
9 tasks
|
Nit: the summary could do with a short example. Currently the first few code snippets are about alternatives. I really like the idea. I'm a little less sure about the syntax because in this case an attribute is changing the type, not just its implementation. Ideally we'd have a new keyword, e.g. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add
#[repr(_, open)]on field-less (C-style) enums to allow the enum to contain unknown variants, which enables using the enum directly in FFI.Enums with the
openmodifier cannot be matched on exhaustively without the use of a wildcard arm. This feature is similar but distinct from the#[non_exhaustive]attribute, since it works on an ABI level and applies in the defining module as well.Based on @thomcc's initial work on a similar RFC. This kind of functionality has also been discussed in the past on the internals forum, more recently on Zulip and possibly many more times before that.
Please try to create inline comments for discussions to keep this RFC manageable for me.
Rendered.