[type-layout] Document bit validity of structs and padding
This intentionally omits discussions of enums and unions. Enum bit validity is well-defined, but it is difficult to articulate concisely. Union bit validity is still not nailed down.
It does not permit that, no, as we can relax validity invariants.
On Thu, Oct 10, 2024, 21:20 Joshua Liebow-Feeser @.***> wrote:
@.**** commented on this pull request.
In src/type-layout.md https://github.com/rust-lang/reference/pull/1630#discussion_r1796293210:
+Padding bytes have no bit validity requirement: it is always well-defined +to write any byte value - including an uninitialized byte - to any byte of +padding.
IMO bit validity (at least as I've used it) is a tad stronger than that: it also permits unsafe code to assume that it won't see certain values produced by safe Rust. That implies that it also constrains what low-level representations can be produced by the "encoding" operation you described.
I don't see any reason why explicitly documenting encoding and decoding separately is a problem. I'd just want to make sure we can still derive the stronger notion of bit validity that I described from whatever guarantees are made regarding encoding and decoding.
— Reply to this email directly, view it on GitHub https://github.com/rust-lang/reference/pull/1630#discussion_r1796293210, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGLD22HV3WP7ABLDQLOSETZ24RVTAVCNFSM6AAAAABOZMPY6WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNRRG4ZTIOJZGM . You are receiving this because you commented.Message ID: @.***>
@rustbot author
:umbrella: The latest upstream changes (possibly bf115a45b6bbc97cafa9e7c90106c5856fd965ea) made this pull request unmergeable. Please resolve the merge conflicts.
By the way, this can be considered an incremental part of the larger effort started in #1664. Commenting to create the link between both PRs since there was none yet.