repr(ordered_fields) #3845

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

text/3845-repr-ordered-fields.md

Rework struct layout description.

text/3845-repr-ordered-fields.md

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

text/3845-repr-ordered-fields.md

+# 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>

text/3845-repr-ordered-fields.md

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

text/3845-repr-ordered-fields.md

+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

text/3845-repr-ordered-fields.md

+
+`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.

text/3845-repr-ordered-fields.md

Co-authored-by: Ralf Jung <post@ralfj.de>

text/3845-repr-ordered-fields.md

RalfJung · 2025-09-25T07:17:29Z

The RFC does a good job at establishing that there are two potentially distinct use for today's repr(C). What the RFC doesn't do (and I think is important) is evaluate why it's actually a problem to conflate these two. Specifically curious what use cases break if we just "fix" reprC).

This post and its neighbors discuss some of that.

…enkov repr(transparent): do not consider repr(C) types to be 1-ZST Context: rust-lang/unsafe-code-guidelines#552 This experiments with a [suggestion](rust-lang/rfcs#3845 (comment)) by `@RustyYato` to stop considering repr(C) types as 1-ZST for the purpose of repr(transparent). If we go with rust-lang/rfcs#3845 (or another approach for fixing repr(C)), they will anyway not be ZST on all targets any more, so this removes a portability hazard. Furthermore, zero-sized repr(C) structs [may have to be treated](rust-lang/unsafe-code-guidelines#552 (comment)) as non-ZST for the win64 ABI (at least that's what gcc/clang do), so allowing them to be ignored in repr(transparent) types is not entirely coherent. Turns out we already have an FCW for repr(transparent), namely rust-lang#78586. This extends that lint to also check for repr(C).

…enkov repr(transparent): do not consider repr(C) types to be 1-ZST Context: rust-lang/unsafe-code-guidelines#552 This experiments with a [suggestion](rust-lang/rfcs#3845 (comment)) by ``@RustyYato`` to stop considering repr(C) types as 1-ZST for the purpose of repr(transparent). If we go with rust-lang/rfcs#3845 (or another approach for fixing repr(C)), they will anyway not be ZST on all targets any more, so this removes a portability hazard. Furthermore, zero-sized repr(C) structs [may have to be treated](rust-lang/unsafe-code-guidelines#552 (comment)) as non-ZST for the win64 ABI (at least that's what gcc/clang do), so allowing them to be ignored in repr(transparent) types is not entirely coherent. Turns out we already have an FCW for repr(transparent), namely rust-lang#78586. This extends that lint to also check for repr(C).

…enkov repr(transparent): do not consider repr(C) types to be 1-ZST Context: rust-lang/unsafe-code-guidelines#552 This experiments with a [suggestion](rust-lang/rfcs#3845 (comment)) by ```@RustyYato``` to stop considering repr(C) types as 1-ZST for the purpose of repr(transparent). If we go with rust-lang/rfcs#3845 (or another approach for fixing repr(C)), they will anyway not be ZST on all targets any more, so this removes a portability hazard. Furthermore, zero-sized repr(C) structs [may have to be treated](rust-lang/unsafe-code-guidelines#552 (comment)) as non-ZST for the win64 ABI (at least that's what gcc/clang do), so allowing them to be ignored in repr(transparent) types is not entirely coherent. Turns out we already have an FCW for repr(transparent), namely rust-lang#78586. This extends that lint to also check for repr(C).

Rollup merge of #147185 - RalfJung:repr-c-not-zst, r=petrochenkov repr(transparent): do not consider repr(C) types to be 1-ZST Context: rust-lang/unsafe-code-guidelines#552 This experiments with a [suggestion](rust-lang/rfcs#3845 (comment)) by ```@RustyYato``` to stop considering repr(C) types as 1-ZST for the purpose of repr(transparent). If we go with rust-lang/rfcs#3845 (or another approach for fixing repr(C)), they will anyway not be ZST on all targets any more, so this removes a portability hazard. Furthermore, zero-sized repr(C) structs [may have to be treated](rust-lang/unsafe-code-guidelines#552 (comment)) as non-ZST for the win64 ABI (at least that's what gcc/clang do), so allowing them to be ignored in repr(transparent) types is not entirely coherent. Turns out we already have an FCW for repr(transparent), namely #78586. This extends that lint to also check for repr(C).

repr(transparent): do not consider repr(C) types to be 1-ZST Context: rust-lang/unsafe-code-guidelines#552 This experiments with a [suggestion](rust-lang/rfcs#3845 (comment)) by ```@RustyYato``` to stop considering repr(C) types as 1-ZST for the purpose of repr(transparent). If we go with rust-lang/rfcs#3845 (or another approach for fixing repr(C)), they will anyway not be ZST on all targets any more, so this removes a portability hazard. Furthermore, zero-sized repr(C) structs [may have to be treated](rust-lang/unsafe-code-guidelines#552 (comment)) as non-ZST for the win64 ABI (at least that's what gcc/clang do), so allowing them to be ignored in repr(transparent) types is not entirely coherent. Turns out we already have an FCW for repr(transparent), namely rust-lang/rust#78586. This extends that lint to also check for repr(C).

RalfJung · 2026-01-26T08:29:16Z

@RustyYato So, an chance you could incorporate that kind of motivation into the RFC? Also let us know if you'd like help with editing the RFC.

text/3845-repr-ordered-fields.md

clarify that we are describing the behavior of repr(ordered_fields) clarify differences with `repr(iN)`

teor2345

Some typo fixes, and an idea for a repr name

text/3845-repr-ordered-fields.md

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

text/3845-repr-ordered-fields.md

Co-authored-by: Jules Bertholet <jules.bertholet@gmail.com>

madsmtm · 2026-01-30T17:32:57Z

text/3845-repr-ordered-fields.md

+	* This is only necessary for those who are updating to the new edition. Which is as little churn as we can make it
+* If we don't end up switching `repr(C)` to mean the system layout/ABI, then we will have two identical reprs, which may cause confusion.
+
+# Rationale and alternatives


The issues that this fixes are with ZSTs over FFI (basically never done), an AIX bug (tier 3 target), and might help with an x86_32 MSVC bug. That seems... Kinda weak IMO, compared to like a million #[repr(C)]s out there that currently work.

Maybe instead of planning to change #[repr(C)], an alternative could be to introduce both #[repr(ordered_fields)] and #[repr(bikeshed_broken_but_actual_C_struct_repr)], and have #[repr(C)] guaranteed to be an alias of #[repr(ordered_fields)]? And then we deprecate #[repr(C)] once those two are in everyone's MSRV and such.

This would avoid the hard issues of "when do we break this" and "oops, things act differently in edition 2027". Having previously fine unsafe code become unsound over an edition is dangerous territory.

Building on top of that, another alternative would be to not deprecate at all, and instead leave #[repr(C)] as an alias of #[repr(ordered_fields)]. (#[repr(C)] is what the C standard says, it's just certain compilers that don't really follow the standard).

And then we instead introduce more specific checks like "type is #[repr(C)] + type is ZST or has 8-byte fields + type is used in FFI" -> "warn and suggest #[repr(bikeshed_broken_but_actual_C_struct_repr)]".

This would allow #[repr(C)] struct Point { x: c_int, y: c_int } and such to continue working just fine.

There's also the problem of aligned structs inside packed structs.

(#[repr(C)] is what the C standard says, it's just certain compilers that don't really follow the standard).

I don't think this is correct. The C standard says nothing about struct layout. Rust just made incorrect assumptions. We should fix that mistake instead of doubling down on it.

And then we instead introduce more specific checks like "type is #[repr(C)] + type is ZST or has 8-byte fields + type is used in FFI" -> "warn and suggest #[repr(bikeshed_broken_but_actual_C_struct_repr)]".

Lints won't work when generics are involved.

This would avoid the hard issues of "when do we break this" and "oops, things act differently in edition 2027". Having previously fine unsafe code become unsound over an edition is dangerous territory.

So should edition migration change repr(C) in 2024 to repr(ordered_fields) in 202x to ensure the meaning is preserved?

Note that for the same reason that most repr(C) out there work, also most unsafe code working with repr(C) won't become unsound.

Or maybe yet another option: we do introduce repr(psABI) for "the (C) layout defined by the psABI of the current target". And then for all repr(C) we check whether for this type, repr(ordered_fields) and repr(psABI) agree for all targets (or just for the current target?). If yes, all is good, if not

on old editions: warn and continue with repr(ordered_fields)

on new editions: error

Note that pretty much every repr(C) struct with a generic field would trigger the warning/error.

There's also the problem of aligned structs inside packed structs.

Sorry, didn't fully grok that issue, so I assigned it a lower priority in my head. I'm not certain here, but I don't think that's incompatible with the alternatives I proposed?

I don't think this is correct. The C standard says nothing about struct layout. Rust just made incorrect assumptions. We should fix that mistake instead of doubling down on it.

Perhaps. In any case, I'm not convinced that there isn't a bunch of C code that is broken by this as well because they make the same assumption Rust does, and thus the argument that these are bugs in the C compilers instead.

Lints won't work when generics are involved.

The lint would probably have to happen on the actual usage in extern "C" fns (either declarations or definitions) a la improper_ctypes*, and generics are fairly rare in those places.

, I'm not convinced that there isn't a bunch of C code that is broken by this as well because they make the same assumption Rust does, and thus the argument that these are bugs in the C compilers instead.

IMO it's fairly clear that such code is buggy or at least non-portable C code. I see no basis for arguing that these C compilers are wrong. They are just strange.

The lint would probably have to happen on the actual usage in extern "C" fns (either declarations or definitions) a la improper_ctypes*, and generics are fairly rare in those places.

That's best-effort since not all types that cross the ABI boundary might be visible there (passing around void* and casting later is a common idiom after all).

Or maybe yet another option: we do introduce repr(psABI) [...]

I like this idea a lot more than the current RFC.

Also unsure how strict such a check should be, maybe:

If affected platform:

on old editions: warn and continue with repr(ordered_fields)

on new editions: error

If not affected platform:

on old editions: continue with repr(ordered_fields)

on new editions: warn and continue with repr(ordered_fields)

That'd probably make the change more gradual.

IMO it's fairly clear that such code is buggy or at least non-portable C code. I see no basis for arguing that these C compilers are wrong. They are just strange.

I'll trust you to know better on that subject, I haven't actually read the C standard or anything.

imo repr(psABI) is a terrible name, since that's way more obscure than C, I wouldn't expect even decent C and Rust programmers to know what it is.

We only have two options:

Change what repr(C) means. Can be done over an edition, but will still break copying any old material.

Consider repr(C) "burnt" at least for all cases where the C layout is different from repr(ordered_fields), and come up with a different name, which will be terrible.

I think I saw someone propose repr(system) somewhere, but I don’t remember who exactly.

That was meant to have a slightly different meaning, just like extern "systems" (which already exists) is not the same as extern "C".

RalfJung · 2026-01-31T13:30:37Z

text/3845-repr-ordered-fields.md

+* match layouts of two different types (or even, two different monomorphizations of the same generic type)
+	* see [here](https://github.com/rust-lang/rust/pull/68099), where in `alloc` this is done for `Rc` and `Arc` to give a consistent layout for all `T`


This last kind of use isn't actually broken by "just fixing repr(C)", right? Layout is still just a function of the field types.

I guess it's not broken on it's own. But changing the layout of these types is a little suspicious, since usually if you want them to have a consistent layout, then you are also expoiting that fact somewhere else.

edit motivation section

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

text/3845-repr-ordered-fields.md Show resolved Hide resolved

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

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

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

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

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 reviewed Sep 3, 2025

View reviewed changes

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

RalfJung reviewed Sep 3, 2025

View reviewed changes

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

RustyYato and others added 2 commits September 3, 2025 14:15

Apply suggestions from code review

e7bd72a

Co-authored-by: Ralf Jung <post@ralfj.de>

update motivation section for AIX

7d7b01a

RalfJung reviewed Sep 3, 2025

View reviewed changes

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

Update AIX section and minor rewording throughout

81a1a42

Nadrieril mentioned this pull request Sep 8, 2025

Compute layouts on demand AeneasVerif/charon#800

Closed

traviscross added P-lang-drag-3 Lang team prioritization drag level 3. and removed P-lang-drag-2 Lang team prioritization drag level 2. labels Sep 10, 2025

workingjubilee mentioned this pull request Sep 25, 2025

compiler: remove AIX's uses_power_alignment lint rust-lang/rust#142310

Open

RalfJung mentioned this pull request Sep 30, 2025

repr(transparent): do not consider repr(C) types to be 1-ZST rust-lang/rust#147185

Merged

bjorn3 reviewed Jan 26, 2026

View reviewed changes

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

RustyYato commented Jan 26, 2026

View reviewed changes

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

some clarifications about the spec

98be259

clarify that we are describing the behavior of repr(ordered_fields) clarify differences with `repr(iN)`

teor2345 reviewed Jan 27, 2026

View reviewed changes

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

text/3845-repr-ordered-fields.md Outdated Show resolved Hide resolved

text/3845-repr-ordered-fields.md Show resolved Hide resolved

Apply suggestions from code review

3f41cb3

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

Jules-Bertholet reviewed Jan 27, 2026

View reviewed changes

text/3845-repr-ordered-fields.md Show resolved Hide resolved

Apply suggestion from code review

87801ba

Co-authored-by: Jules Bertholet <jules.bertholet@gmail.com>

madsmtm reviewed Jan 30, 2026

View reviewed changes

RalfJung mentioned this pull request Jan 31, 2026

AIX repr(C) struct layout does not always match C compiler rust-lang/rust#151910

Open

RalfJung reviewed Jan 31, 2026

View reviewed changes

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

	`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.

		* match layouts of two different types (or even, two different monomorphizations of the same generic type)
		* see [here](https://github.com/rust-lang/rust/pull/68099), where in `alloc` this is done for `Rc` and `Arc` to give a consistent layout for all `T`

repr(ordered_fields) #3845

Are you sure you want to change the base?

repr(ordered_fields) #3845

Uh oh!

Conversation

RustyYato commented Aug 5, 2025 • edited 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!

Uh oh!

Uh oh!

Uh oh!

RalfJung commented Sep 25, 2025

Uh oh!

RalfJung commented Jan 26, 2026

Uh oh!

Uh oh!

Uh oh!

teor2345 left a comment

Choose a reason for hiding this comment

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!

RalfJung Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

madsmtm Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

RustyYato commented Aug 5, 2025 •

edited

Loading

clarfonthey commented Aug 5, 2025 •

edited

Loading

RalfJung Jan 30, 2026 •

edited

Loading

madsmtm Jan 30, 2026 •

edited

Loading