Repository navigation
Tracking issue for RFC 1758: Specify repr(transparent) #43036
Description
Activity
- changed the title
[-]Tracking issue for RFC 1758: Specify [/-][+]Tracking issue for RFC 1758: Specify `repr(transparent)`[/+]on Jul 3, 2017 Mentoring instructions unavailable. This is sadly not that easy, as we have too much code that still relies on assumptions that such types do not exist. I have an in-progress branch which requires implementing the necessary support for "newtype unpacking" but no time frame for completion.
Is making types like
Cellrepr(transparent)(which e.g. rust-lang/rfcs#1789 relies on) part of the implementation of the RFC or would that require its own RFC?- added a commit that references this issue
on Oct 9, 2017 - added a commit that references this issue
on Oct 11, 2017 The RFC makes contradictory statements about the interaction with
repr(align(N)): The Motivation section saysGiven this attribute delegates all representation concerns, no other repr attribute should be present on the type. This means the following definitions are illegal:
#[repr(transparent, align = "128")] struct BogusAlign(f64); #[repr(transparent, packed)] struct BogusPacked(f64);
... while the Detailed Design section says:
This new representation cannot be used with any other representation attribute but alignment, to be able to specify a transparent wrapper with additional alignment constraints:
#[repr(transparent, align = "128")] struct OverAligned(f64); // Behaves as a bare f64 with 128 bits alignment. #[repr(C, transparent)] struct BogusRepr(f64); // Nonsensical, repr cannot be C and transparent.
AFAICT the RFC initially prohibited repr(transparent, align), then in the discussion some people asked for it to be allowed, but later the rationale for that was called into question and there was no consensus or (explicit) decision. So it's hard to see which alternative was intended to be the final state by the RFC author and the lang team.
I'd disallow it since it significantly complicates the implementation IMO. Is there any motivation for allowing the combination?
Discussion is mostly rust-lang/rfcs#1758 (comment) plus the immediate replies. The motivation is not immediately clear to me, just that a nested wrapper type with
align(N)and notransparentis not equivalent to a single type withrepr(align(N), transparent). Perhaps @briansmith or @nox could elaborate?@nox tells me on IRC they have no use case for it. Let's amend the RFC to consistently reject repr(transparent, align). If someone does find a use case, they can deal with the implementation effort and amend the RFC again.
Sorry, it's been forever since we had that conversation. Maybe I'm overlooking something, but I think
#[repr(transparent, align=16)]would be very common. For example:#[repr(transparent, align=16)] struct Aes256Key([u8; 32]); #[repr(transparent, align=16)] struct AesNonce([u8; 16]); // Keep this in sync with the C definition in aes.h #[repr(C)] struct Aes256Context { key: Aes256Key, ... nonce: AesNonce, ... } extern aes256Encrypt(context: &mut Aes256Context, ...);
I'm not sure how one would express this otherwise.
Is there any ABI where you need
#[repr(transparent)]in conjunction with an aggregate type (e.g. a non-transparent struct, or in your case, an array)?
AFAIK, none of the ABIs we support today has such a distinction, so#[repr(transparent)]wouldn't really have to do anything to be correct in those cases, but maybe I'm wrong?EDIT: Also, are you ever passing or returning
Aes256KeyorAesNonceby value to/from a function? That's the only time#[repr(transparent)]actually does anything.
The calling convention part of the ABI is orthogonal to the memory layout, and the latter is identical between a struct with one field and the field itself, pretty much everywhere.Reacted by Hanna Kruppe63 remaining items
Oops, this should have been closed by #51562.
- added a commit that references this issue
on Sep 6, 2022 - added a commit that references this issue
on Feb 20, 2026
RFC
This is a tracking issue for the RFC "Specify
repr(transparent)" (rust-lang/rfcs#1758).Steps: