https://doc.rust-lang.org/1.30.0/reference/items/unions.html says "Inactive fields can be accessed as well (using the same syntax) if they are sufficiently layout compatible" but the RFC says that reading a (a part of a) member that wasn't the last one written to is undefined behavior. I had already written code that assumes that the Rust reference is correct. I went back and added
#[repr(C)] to my unions to make them safer as there seems to be some dispute about whether
#[repr(C)] guarantees more than
#[repr(Rust)] here. What's the current status?
#[repr(C)] won't guarantee anything more than
#[repr(Rust)]. I think that they just defined it in the transition from RFC to language?
basically, C rules, not C++ rules
I think that has to be the case, because it would be very easy to accidentally get undefined behavior by forgetting the
#[repr(C)]; I've done it myself already. Plus people don't expect "C" to be safer than "Rust"; it'd be counter-intuitive.
the plan is for Rust to not have any notion of "active/inactive union fields". Instead, every access just interprets the data stored in memory at the type used for the access. basically, unions field access is sugar for transmute, no more.
(well, my plan anyway, but it seems like most people agree)
wow there is some strange structure in the reference... there is
There are types that aren't items and items that aren't types, so there has to be a section for both of them. I think that the plan is to merge the struct, enumeration and union type pages and put most of the information on the item pages.
@RalfJ a C++ reference is not a “lawyer object”. Pretty unfortunate that one has to be aware of that when using C++ or reading the standard.
@gnzlbg not sure what this is a reply to?
I was talking about the Rust reference above
sent a PR to remove the notion of an "active field": https://github.com/rust-lang-nursery/reference/pull/478
Oh I meant to reply to the nomenclature (place, ..) topic - guess I need to figure out how the mobile app works.
people don't expect "C" to be safer than "Rust"; it'd be counter-intuitive
I disagree; for unsafe code that plays games with struct layout, for example,
repr(C) is "safer" (and required)
@RalfJ I understand that
repr(C) actually is safer than
repr(Rust). However, that is almost definitely surprising to people who don't think about these things as much as we do.