Warning

This post was published 36 days ago. The information described in this article may have changed.

Info

This post is auto-generated from RSS feed The Rust Programming Language Forum - Latest topics. Source: Why does this #[repr(C)] struct compile when inner type lacks #[repr(transparent)]?

Hi everyone,

I was reading RFC 1758 regarding the #[repr(transparent)] attribute and came across this section:

As a matter of optimisation, eligible #[repr(Rust)] structs behave as if they were #[repr(transparent)] but as an implementation detail that can't be relied upon by users.
struct ImplicitlyTransparentWrapper(f64);

#[repr(C)]
struct BogusRepr {
    // While ImplicitlyTransparentWrapper implicitly has the same representation
    // as f64, this will fail to compile because ImplicitlyTransparentWrapper
    // has no explicit transparent or C representation.
    wrapper: ImplicitlyTransparentWrapper,
}

The RFC says this code should fail to compile because ImplicitlyTransparentWrapper does not have an explicit #[repr(transparent)] or #[repr(C)].

However, when I tried this exact code on stable Rust, it does compile without any issues.

Questions:

1. Has there been a change in how the Rust compiler handles representation this kind of structs?
2. Even if it compiles, is it still considered sound to use this pattern in FFI contexts or in transmuting?

Would appreciate any clarification or pointers to newer discussions or RFCs that reflect the current behavior. Thanks!

4 posts - 3 participants

Read full topic

🏷️ rust_feed