rust-lang
repr(ordered_fields)
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.
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.
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 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.
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 userepr(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 betweenrepr(C)andrepr(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.
Nominating this so that we can do a preliminary vibe-check on it in a lang triage meeting.
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).
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).
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.
