repr(ordered_fields) by RustyYato · Pull Request #3845 · rust-lang/rfcs

RustyYato · 2025-08-05T16:01:05Z

Add repr(ordered_fields) and provide a migration path to switch users from repr(C) to repr(ordered_fields), then change the meaning of repr(C) in the next edition.

This RFC is meant to be an MVP, and any extensions (for example, adding more reprs) are not in scope. This is done to make it as easy as possible to accept this RFC and make progress on the issue of repr(C) serving two opposing roles.

Rendered

To avoid endless bikeshedding, I'll make a poll if this RFC is accepted with all the potential names for the new repr. If you have a new name, I'll add it to the list of names in the unresolved questions section, and will include it in the poll.

initial RFC

clarfonthey · 2025-08-05T18:50:08Z

Not to add too many extra colours to the list, but repr(consistent) feels like a good name for this, since the purpose is to provide a consistent layout that does not depend on generics, compiler version, or target. The important thing is just that it's consistent, not that it matches what C does.

(Note: those three things should cover every case I've seen that uses repr(C) that should use repr(ordered_fields), but please feel free to correct me if I missed anything.)

Whereas repr(C) is explicitly, match what C does.

Also, while it may be more technical than most users need to understand, it would be helpful if the RFC reiterated the current issues with repr(C) that we want to fix, and potential future differences between repr(C) and repr(ordered_fields) that could pop up. I've read some of them but am not 100% sure of the details, and it would be nice to keep as part of the RFC.

Lokathor · 2025-08-05T18:52:33Z

Just as a small point of style the Guide Level Explanation is usually "what would be written in the rust tutorial book", and the Reference Level Explanation is "what could be written into the Rust Reference". This isn't a strict requirement, but personally I'd like to see the Reference Level part written out. Using the present tense, as if the RFC was accepted and implemented.

add more unresolved questions

Rework struct layout description.

programmerjake · 2025-08-05T23:08:17Z

+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+`repr(ordered_fields)` is a new representation that can be applied to `struct`, `enum`, and `union` to give them a consistent, cross-platform, and predictable in memory layout.


Suggested change

`repr(ordered_fields)` is a new representation that can be applied to `struct`, `enum`, and `union` to give them a consistent, cross-platform, and predictable in memory layout.

`repr(ordered_fields)` is a new representation that can be applied to `struct`, `enum`, and `union` to give them a consistent, cross-platform, and predictable in-memory layout.

"cross-platform" -- the layout will differ when there are different layouts for struct members' types, in particular primitive types can have different alignments which changes the amount of padding.

e.g., #[repr(ordered_fields)] struct S(u8, f64); doesn't have the same layout on x86_64 and i686

Good point, this will need to be documented as a hazard in the ordered_fields docs. However, the repr itself will be cross-platform. For example, #[repr(ordered_fields)] struct Cross([u8; 3], SomeEnum); will be truly cross-platform (given that SomeEnum is!).

Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>

moonheart08 · 2025-08-06T10:29:09Z

Not to add too many extra colours to the list, but repr(consistent) feels like a good name for this, since the purpose is to provide a consistent layout that does not depend on generics, compiler version, or target. The important thing is just that it's consistent, not that it matches what C does.

(Note: those three things should cover every case I've seen that uses repr(C) that should use repr(ordered_fields), but please feel free to correct me if I missed anything.)

Whereas repr(C) is explicitly, match what C does.

Also, while it may be more technical than most users need to understand, it would be helpful if the RFC reiterated the current issues with repr(C) that we want to fix, and potential future differences between repr(C) and repr(ordered_fields) that could pop up. I've read some of them but am not 100% sure of the details, and it would be nice to keep as part of the RFC.

Just voicing support for repr(consistent) as naming.
Aside from the above, it more clearly hones in on the primary promises of the RFC, which is not just ordering but also exact type representation for things like enums. Field ordering is not the only thing it promises.

joshtriplett · 2025-08-06T17:31:50Z

Nominating this so that we can do a preliminary vibe-check on it in a lang triage meeting.

scottmcm · 2025-08-06T21:44:39Z

+Currently `repr(C)` serves two roles
+1. Provide a consistent, cross-platform, predictable layout for a given type
+2. Match the target C compiler's struct/union layout algorithm and ABI


Big fan of doing this split, especially for structs. (It's less obvious what choices to make for other things, IMHO, but at least for structs this is something I've wanted for ages, so that for example Layout::extend can talk about it instead of C.)

Pondering the bikeshed: declaration_order or something could also be used to directly say what you're getting.

(This could be contrasted with other potential reprs that I wouldn't expect this RFC to add, but could consider as future work, like a deterministic_by_size_and_alignment where some restricted set of optimizations are allowed but you can be sure that usize and NonNull<String> can be mixed between different types while still getting the "same" field offsets, for example.)

I think this is also useful for unions, so we don't need to rely on repr(C) to ensure that all fields of a union are at offset 0.

This could be contrasted with other potential reprs that I wouldn't expect this RFC to add...

This also works as an argument against names like repr(consistent), since there are multiple consistent and useful repr, making it not descriptive enough.

I do think that declaration_order or ordered_fields is a bit weird on a union, because of course they're not really in any "order".

It makes me ponder whether we should just have repr(offset_zero) for unions to be explicit about it, or something.

(Which makes me think of other things like addressing rust-lang/unsafe-code-guidelines#494 by having a different constructs for "bag of maybeuninit stuff that overlap" vs "distinct options with an active-variant rule for enum-but-without-stored-discriminant". But those are definitely not this RFC.)

I don't mind spelling it as repr(offset_zero) for unions if that helps get this RFC accepted 😄. However, I have a sneaking suspicion that this isn't the contentious part of this RFC.
I know the name isn't optimal (intentionally). This can be hashed out after the RFC is accepted (or even give a different name for all of struct, union, and enum).
The most important bit for me is just that we do the split (for all of struct, union, and enum, to be consistent).

RustyYato · 2025-08-06T22:30:49Z

I've updated how enums's tags are specified, now they just defer to whatever repr(C)'s tag type is. This is done to reduce the friction of switching from repr(C) to repr(ordered_fields). To ensure that all uses of repr(ordered_fields) can be cross-platform, I've adding a lint to ensure that the user also adds an explicit repr for repr(uN)/repr(iN).

Mark-Simulacrum · 2025-08-06T22:49:49Z

+
+`repr(C)` in edition <= 2024 is an alias for `repr(ordered_fields)` and in all other editions, it matches the default C compiler for the given target for structs, unions, and field-less enums. Enums with fields will be laid out as if they are a union of structs with the corresponding fields.
+
+Using `repr(C)` in editions <= 2024 triggers a lint to use `repr(ordered_fields)` as a future compatibility lint with a machine-applicable fix. If you are using `repr(C)` for FFI, then you may silence this lint. If you are using `repr(C)` for anything else, please switch over to `repr(ordered_fields)` so updating to future editions doesn't change the meaning of your code.


I think this is too noisy. Most code out there using repr(C) is probably fine - IIUC, if you're not targeting Windows or AIX, maybe definitely fine? - and having a bunch of allow(...) across a bunch of projects seems unfortunate.

Maybe we can either (a) only enable the lint for migration, i.e., the next edition's cargo fix would add allows for you or (b) we find some new name... C2 for the existing repr(C) usage to avoid allows. But (b) also seems too noisy to me.

Maybe it could just be an optional edition compatibility lint, so if someone enables e.g. rust_20xx_compatibility it shows up but otherwise not.

(a) only enable the lint for migration

That was the intention, hence the name edition_2024_repr_c. I'll make this more clear, that this is intended to be a migration lint.

Rustfix would update to #[repr(ordered_fields)] to preserve the current behavior. For the FFI crates, #![allow(edition_2024_repr_c)] at the top of lib.rs would suffice. If you have a mix of FFI and non-FFI uses of repr(C), then you'll have to do the work to figure out which is which, no matter what option is chosen to update repr(C) - even adding repr(C2), since then the FFI use case would need to update all their reprs to repr(C2).

Overall, I think this scheme only significantly burdens those who have a mix of FFI and non-FFI uses of repr(C). But they were going to be burdened no matter what option was chosen.

Is the new wording/lints too noisy still?

I think the new wording is still too noisy. We shouldn't assume that most people using repr(C) are using it for ordering rather than FFI.

That wasn't my intention, but I don't see another way to do all of the following in the next edition:

make repr(C) mean - same layout/ABI as what the standard C compiler does

make repr(ordered_fields) - the same algorithm that's listed for repr(C) in the Rust reference

ensure that everyone who upgrades to the next edition gets the layout they need (as long as they read the warnings and follow the given advice)

make it as painless as possible for people who don't mix FFI and stable ordering cases (which I suspect is the vast majority of people). In other words, each crate currently uses repr(C) either exclusively for FFI or exclusively for some stable layout.

for people who do mix FFI and stable ordering cases in one crate, at least the warning should give them all the places they need to double-check, and they can silence the warning on a case-by-case basis.

I'm open to suggestions on how to handle the diagnostics. Within these constraints, I think my solution is the only real option we have. If there are some objections to these constraints, I would like to hear those too, maybe I missed the mark with these constraints, and missed a potential solution because of it.

@DemiMarie said this in a comment:

Would it be possible to rename repr(C) to something else? That way repr(C) becomes a compile-time error rather than silently changing behavior.

I laid out my design axioms above. I believe that making a new repr and deprecating repr(C) is too costly. Especially when the most prevalent use-case of repr(C) is for FFI. A use-case which would benefit from bug fixes that could happen after this RFC.

edit motivation section

DemiMarie · 2026-02-22T14:49:48Z

Would it be possible to rename repr(C) to something else? That way repr(C) becomes a compile-time error rather than silently changing behavior.

RustyYato · 2026-02-22T16:37:03Z

@DemiMarie, I have responded here. Since I believe that thread is related to your comment.

reorg questions again

RalfJung · 2026-04-15T18:07:41Z

+The `suspicious_repr_c` lint takes precedence over `edition_2024_repr_c`.
+
+```
+warning: use of `repr(C)` in type `Foo`
+  --> src/main.rs:14:10
+   |
+14 |     #[repr(C)]
+   |       ^^^^^^^ help: consider switching to `repr(ordered_fields)`
+   |     struct Foo {
+   |
+   = note: `#[warn(suspicious_repr_c)]` on by default
+   = note: `repr(C)` is intended for FFI, and since there are no `extern` blocks or functions, it's likely that you meant to use `repr(ordered_fields)` to get a stable and consistent layout for your type
+```
+
+After enough time has passed, and the community has switched over:
+This makes it easier to tell *why* the `repr` was applied to a given struct. If `repr(C)`, it's about FFI and interop. If `repr(ordered_fields)`, then it's for a dependable layout.


What is this 2nd lint? When does it fire? What does it mean to "take precedence"? What changes about it after enough time has passed? I am confused by every part of this paragraph. ;)

View changes since the review

After rereading this section, I completely agree. I'll rework it.

* explain suspicious_repr_c lint * update layout calc for enums * remove unresolved question about union niches

RustyYato · 2026-04-16T14:58:25Z

I've reworked large parts of this RFC following the lang-team design meeting (meeting notes).

tldr:
following from the meeting

there are some more reprs to make the migration smoother
some lints have changed
- edition_2024_repr_c now uses one of the new reprs as a machine applicable fix
- suspicious_repr_c is now allow by default
some lints have been added to manage the new reprs

a simplification

repr(ordered_fields) on enums now requires the tag type, this way we don't have platform-specific behavior on the pure Rust repr.
repr(ordered_fields) will not have a stable ABI (edit: calling convention)

This does mean that repr(ordered_fields) won't be equivalent to repr(C) on the current edition. However, I think this is fine. A future propsal can endow repr(ordered_fields) with a calling convention, and if something like #3659 is accepted, then you could use (for example, if c_int happens to be the correct discriminant type) repr(ordered_fields, tag = core::ffi::c_int) to get the same layout as current repr(C) using repr(ordered_fields). However, I don't think anyone using repr(C) currently only for the predictable layout actually wants the same layout as the current repr(C).

I'll be updating this RFC again to refine it in over the next week or so.

…iler

RalfJung · 2026-04-16T15:18:24Z

if something like #3659 is accepted, then you could use repr(ordered_fields, tag = core::ffi::c_int) to get the same layout as current repr(C) using repr(ordered_fields)

This is not correct. Enums in C don't always use c_int. On some targets, they use smaller types when possible (i.e., if all discriminants fit).

bjorn3 · 2026-04-16T15:37:04Z

repr(ordered_fields) will not have a stable ABI

Do you mean stable calling convention or stable memory layout?

kennytm · 2026-04-16T15:37:11Z

+* `repr(C#editionCurr)`
+* `repr(C#editionNext)`


😕 do these mean the literal keyword "editionCurr" and "editionNext" or just a placeholder for "2024" / "2027"?

also a bit awkward as this looks like related to C#.

View changes since the review

These are just placeholders, I don't want to commit to a specific edition. Personally I think this should be in 2027, but I think forcing the issue won't help get this over the finish line.

I just realized what you meant by looking related to C#, good point! Like all names in this RFC, I'm happy to add names to the list and bikeshed them if this RFC gets accepted. So if you have any suggestions, feel free to drop a comment 🙂

RalfJung · 2026-04-16T15:40:46Z

Do you mean stable calling convention or stable memory layout?

Calling convention.

remove section in migration plan about removing the `repr(C#edition*)` reprs add a new spelling to the list

RustyYato added 4 commits August 1, 2025 11:30

Create 0000-repr-ordered-fields.md

e0cdce8

initial RFC

Add a link to the zullip thread

0637bbf

Update RFC with PR number

7e4b0c8

Grammer fixes

61ce0f2

RustyYato added 2 commits August 5, 2025 12:27

Update Motivation to include the exact issue from MSVC

4fa572e

Rework reference level section

755644c

add more unresolved questions

RustyYato commented Aug 5, 2025

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md

RustyYato added 2 commits August 5, 2025 15:49

Add description for union layout

0d0a79b

Rework struct layout description.

Tabs -> Spaces

4f4bf18

RustyYato commented Aug 5, 2025

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md Outdated

programmerjake reviewed Aug 5, 2025

View reviewed changes

RustyYato and others added 3 commits August 5, 2025 16:18

Apply suggestions from code review

063af08

Co-authored-by: Jacob Lifshay <programmerjake@gmail.com>

discriminant -> tag

0c0e429

Qualify alignment assumptions

9e316ff

programmerjake reviewed Aug 6, 2025

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md Outdated

oops, fix typo

a1700b6

ehuss added the T-lang Relevant to the language team, which will review and decide on the RFC. label Aug 6, 2025

joshtriplett added the I-lang-nominated Indicates that an issue has been nominated for prioritizing at the next lang team meeting. label Aug 6, 2025

scottmcm reviewed Aug 6, 2025

View reviewed changes

RustyYato added 2 commits August 6, 2025 15:16

add repr(declaration_order) as a potential spelling

d75a497

Switch enum tag type to defer to repr(C) tag type

6526f5a

Mark-Simulacrum reviewed Aug 6, 2025

View reviewed changes

RustyYato added 3 commits August 7, 2025 08:16

Rework edition_2024_repr_c warning from future compat to edition warning

ed96c1b

Add lints to summary section

01cfb40

edition migraiton lint -> edition compatibility lint

f11567c

RalfJung and others added 2 commits January 31, 2026 15:09

edit motivation section

da8b018

Merge pull request #1 from RalfJung/repr_ordered_fields

843a37e

edit motivation section

RustyYato added 3 commits April 7, 2026 17:52

reorganize unresolved questions

ee16241

minor formatting updates

a1ea5ae

add a discussion link for an unresolved question

5234c1d

reorg questions again

Jules-Bertholet mentioned this pull request Apr 14, 2026

repr(transparent) accepts too many types as ZST (repr_transparent_non_zst_fields, formerly repr_transparent_external_private_fields) rust-lang/rust#78586

Open

RalfJung reviewed Apr 15, 2026

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md Outdated

RalfJung reviewed Apr 15, 2026

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md Outdated

RalfJung reviewed Apr 15, 2026

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md Outdated

RalfJung reviewed Apr 15, 2026

View reviewed changes

Comment thread text/3845-repr-ordered-fields.md Outdated

RustyYato added 6 commits April 16, 2026 08:43

update from review

796423a

* explain suspicious_repr_c lint * update layout calc for enums * remove unresolved question about union niches

first draft after lang-team meeting

785e14c

add an unresolved question for the edition repr C names

55e1b89

update unresolved questions

84f28c1

specify the idiom lints

d95a191

add a note to the migration plan

34cc212

add a note that Rust team can change repr(C) to match target C comp…

db73f7c

…iler

kennytm reviewed Apr 16, 2026

View reviewed changes

RustyYato added 5 commits April 17, 2026 08:42

add some notes to the reference section to document intent

b7eee7a

remove section in migration plan about removing the `repr(C#edition*)` reprs add a new spelling to the list

add migration use-cases and guiding principle

891522b

minor edits

d44a44a

add a note that may be editionNext should actually be edition agnostic

65bff72

fix typo

64dffab

	`repr(ordered_fields)` is a new representation that can be applied to `struct`, `enum`, and `union` to give them a consistent, cross-platform, and predictable in memory layout.
	`repr(ordered_fields)` is a new representation that can be applied to `struct`, `enum`, and `union` to give them a consistent, cross-platform, and predictable in-memory layout.


		`repr(C)` in edition <= 2024 is an alias for `repr(ordered_fields)` and in all other editions, it matches the default C compiler for the given target for structs, unions, and field-less enums. Enums with fields will be laid out as if they are a union of structs with the corresponding fields.

		Using `repr(C)` in editions <= 2024 triggers a lint to use `repr(ordered_fields)` as a future compatibility lint with a machine-applicable fix. If you are using `repr(C)` for FFI, then you may silence this lint. If you are using `repr(C)` for anything else, please switch over to `repr(ordered_fields)` so updating to future editions doesn't change the meaning of your code.

Conversation

RustyYato commented Aug 5, 2025 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clarfonthey commented Aug 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Lokathor commented Aug 5, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

moonheart08 commented Aug 6, 2025

Uh oh!

joshtriplett commented Aug 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RustyYato commented Aug 6, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DemiMarie commented Feb 22, 2026

Uh oh!

RustyYato commented Feb 22, 2026

Uh oh!

Uh oh!

RalfJung Apr 15, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RustyYato commented Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RalfJung commented Apr 16, 2026

Uh oh!

bjorn3 commented Apr 16, 2026

Uh oh!

kennytm Apr 16, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RustyYato Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

RustyYato commented Aug 5, 2025 •

edited by rustbot

Loading

clarfonthey commented Aug 5, 2025 •

edited

Loading

RalfJung Apr 15, 2026 •

edited by rustbot

Loading

RustyYato commented Apr 16, 2026 •

edited

Loading

kennytm Apr 16, 2026 •

edited by rustbot

Loading

RustyYato Apr 16, 2026 •

edited

Loading