docs/pre_rfc_separate_size_stride.md - crubit - Git at Google

 # [Pre-RFC] Allow stride != size

 ## Summary

 Rust should allow for values to be placed at the next aligned position after the
 previous value, ignoring the tail padding of that previous field. This requires
 changing the meaning of "size", so that a value's size in memory (for the
 purpose of reference semantics and layout) is not definitionally the same as the
 distance between consecutive values of that type (its "stride").

 ## Motivation

 Some other languages (C++ and Swift, in particular) can lay out values more
 compactly than Rust conventionally can, leading to better performance at greater
 convenience, and less than ideal Rust interoperability.

 ### Optimization opportunity

 Consider the difference between `(u16, u8, u8)` and `((u16, u8), u8)`. The first
 can fit in 4 bytes, while the second requires 6. A `(u16, u8)` is a 4 byte value
 with 1 byte of tail padding. And a `(T, u8)` can't just stuff the `u8` inside
 the tail padding for `T`! If, instead, we declared that `(u16, u8)` were a **3**
 byte value with alignment 2, then `((u16, u8), u8)` could be 4 bytes instead of
 6. This is not possible today.

 (For backwards compatibility reasons described later, we can't literally do this
 for tuples, but only for user-defined types. But this gives the gist of the
 optimization opportunity this proposal supports.)

 By inventing the concept of a "data size", which doesn't need to be a multiple
 of the alignment, we can allow fields in specially-designed types to be packed
 closer together than they would be today, saving space. This is similar to the
 performance benefits of `#[repr(packed)]`, but safer: all values would still be
 correctly aligned, just placed more closely together.

 This optimization has already been implemented in other programming languages.
 Swift applies this to every type and every field: a type's size excludes tail
 padding, and a neighboring value can be laid out immediately next to it when
 stored in the same type, with no padding between the two. In C++, the
 optimization automatically applies to base classes
 (["EBO"](https://en.cppreference.com/w/cpp/language/ebo), the Empty Base
 Optimization), and is opt-in on fields via the
 [`[[no_unique_address]]`](https://en.cppreference.com/w/cpp/language/attributes/no_unique_address)
 attribute.

 For example, here's an example in [Swift](https://godbolt.org/z/G74ejjsvc) and
 in [C++](https://godbolt.org/z/4esbYrv39). These types are compact! Rust does
 not work like this today.

 ### Interoperability with C++ and Swift

 (Note that the author works on C++ interop, Swift is mentioned for
 completeness.)

 In fact, exactly because this optimization is already implemented in other
 languages, those languages are theoretically not as compatible with Rust as they
 are with each other. In C++ and Swift, writing to a pointer or reference does
 not write to neighboring fields. But if that pointer or reference were passed to
 Rust, and you used any Rust facility to write to it -- whether it were vanilla
 assignment or `ptr::write` -- Rust could overwrite that neighboring field.
 Because the use of this optimization is pervasive in both Swift and C++,
 interoperating with these languages is difficult to do safely.

 Concretely, consider the following C++ struct:

 ```c++
 struct MyStruct {
     [[no_unique_address]] T1 x;
     [[no_unique_address]] T2 y;
     ...
 };
 ```

 Which is equivalent to this Swift struct:

 ```swift
 struct MyStruct {
     let x: T1
     let y: T2
     ...
 }
 ```

 If you are working with cross-language interop, and obtain in Rust a `&mut T1`
 which refers to `x`, and a `&mut T2` which refers to `y`, it may be immediately
 UB, because these references can overlap in Rust: `y` may be located inside what
 Rust would consider the tail padding of the `T1` reference.

 For the same reason, even if you avoid aliasing, if you obtain a `&mut T1` for
 `x`, and then write to it, it may partially overwrite `y` with garbage data,
 causing unexpected or undefined behavior down the line.

 This also cannot be avoided by forbidding the use of `MyStruct`: even if you do
 not directly use it from Rust, from the point of view of Swift and C++, it is
 just a normal struct, and Swift and C++ codebases can freely pass around
 references and pointers to its interior. Someone passing a reference to a `T1`
 may have no idea whether it came from `MyStruct` (unsafe to pass to Rust) or an
 array (safe). You would need to ban (or correctly handle) any C++ and Swift type
 which can have tail padding, in case that padding contains another object.

 (To add insult to injury, the struct `MyStruct` itself -- not just references to
 fields inside it -- cannot be represented directly as so in Rust, either.)

 And anyway, such structs are unavoidable. In Swift, this is the default
 behavior, and pervasive. In C++, `[[no_unique_address]]` is permitted to be used
 pervasively in the standard library, and it is impractical to only interoperate
 with C++ codebases that avoid the standard library.

 In order for C++ and Swift pointers/references to be safely representable in
 Rust as mut references, a `&mut T1` would need to exclude the tail padding,
 which means that Rust would need to separate out the concept of a type's
 interior size from its array stride. And in order to represent `MyStruct` in
 Rust, we would need a way to use the same layout rules that are available in
 these other languages.

 ## Explanation

 (I haven't separated this out to guide-level vs reference-level -- this is a
 pre-RFC! Also, all names TBD.)

 As a quick summary, the proposal is to introduce the following new traits,
 functions, and attributes, and behaviors:

 *   `std::mem::data_size_of<T>()`, returning the size but not necessarily
     rounded to alignment / not necessarily the same as stride.
 *   In the memory model, pointers and references only refer to
     `data_size_of::<T>()` bytes.
 *   `AlignSized`, a trait for types where the data size and stride are the same.
 *   `#[repr(compact)]`, to mark a type as not implementing `AlignSized`, and
     thus having a potentially smaller data size.
 *   `#[compact]`, to mark a field as laid out using the data size instead of the
     stride.

 ## Data size vs stride

 Semantically, Rust types would gain a new kind of size: "data size". This is the
 size of the type, minus the tail padding. In fact, it's in some sense the "true"
 size of the type: array stride is the data size rounded up to alignment.

 Data size would be exposed via a new function `std::mem::data_size_of::<T>()`;
 array stride continues to be returned by `std::mem::size_of::<T>()`.

 The semantics of a write (e.g. via `ptr::write`, `mem::swap`, or assignment) are
 to only write "data size" number of bytes, and a `&T` or `&mut T` would only
 refer to "data size" number of bytes for the purpose of provenance and aliasing
 semantics. (`&[T; 1]`, in contrast, continues to refer to `size_of::<T>()`
 bytes.)

 ## The `AlignSized` trait and `std::array::from_ref`

 It is fundamentally a backwards-incompatible change to make stride and size not
 the same thing, because of functions like
 [`std::array::from_ref`](https://doc.rust-lang.org/stable/std/array/fn.from_ref.html)
 and
 [`std::slice::from_ref`](https://doc.rust-lang.org/stable/std/slice/fn.from_ref.html).
 The existence of these functions means that Rust guarantees that for an
 arbitrary generic type today, that type has identical size and stride.

 This means that if we want to allow for data size and stride to be different,
 they must not be different for any generic type as written today. Existing code
 without trait bounds can call `from_ref`! So we must add an implicit trait bound
 on `AlignSized : Sized`, which, like `Sized`, guarantees that the data size and
 the stride are the same. This trait would be automatically implemented for all
 pre-existing types, which retain their current layout rules.

 In other words, the following two generics are equivalent:

 ```rs
 fn foo<T>() {}
 fn foo<T: Sized + AlignSized>() {}
 ```

 ... and to opt out of requiring `AlignSized`, one must explicitly remove a trait
 bound:

 ```rs
 fn foo2<T: ?AlignSized>() {}
 // AlignSized requires Sized, and so this will also do it:
 fn foo3<T: ?Sized>() {}
 ```

 To opt out of implementing this trait, and to opt in to being placed closer to
 neighboring types inside a compound data structure, types can mark themselves as
 `#[repr(compact)]`. This causes the data size not to be rounded up to alignment:

 ```rs
 #[repr(C, compact)]
 struct MyCompactType(u16, u8);
 // data_size_of::<MyCompactType>() == 3
 // size_of::<MyCompactType>() == 4
 ```

 ## Taking advantage of non-`AlignSized` types with `#[compact]` storage

 If a field is marked `#[compact]`, then the next field is placed after the data
 size of that field, not after the stride. (These can only differ for a
 non-`AlignSized` type.) This provides easy control, and provides compatibility
 with C++, where this behavior can be configured per-field.

 It is an error to apply this attribute on non-`#[repr(C)]` types.

 ```rs
 #[repr(C, compact)]
 struct MyCompactType(u16, u8);

 #[repr(C)]
 struct S {
     #[compact]
     a: MyCompactType,  // occupies the first 3 bytes
     b: u8,             // occupies the 4th byte
 }
 // data_size_of::<S>() == size_of::<S>() == 4
 ```

 ## Example

 Putting everything together:

 ```rs
 #[repr(C, compact)]
 struct MyCompactType(u16, u8);
 // data_size_of::<MyCompactType>() == 3
 // size_of::<MyCompactType>() == 4

 #[repr(C)]
 struct S {
     #[compact]
     a: MyCompactType,  // occupies the first 3 bytes
     b: u8,             // occupies the 4th byte
 }

 // data_size_of::<S>() == size_of::<S>() == 4
 ```

 We can take `mut` references to both fields `a` and `b`, and writes to those
 references will not overlap:

 ```rs
 let mut x : S = ...;
 let S {a, b} = &mut x;
 *a = MyCompactType(4, 2);  // writes 3 bytes
 *b = 0;  // writes 1 byte
 ```

 If we had not applied the `repr(compact)` attribute, **or** had not applied the
 `#[compact]` attribute, then `data_size_of<S>()` would have been 6, and so would
 `size_of<S>()`. The assignment `*a = ...` would have (potentially) written 4
 bytes.

 ## Drawbacks

 ### Backwards compatibility and the `AlignSized` trait

 In order to be backwards compatible, this change requires a new implicit trait
 bound, applied everywhere. However, that makes this change substantially less
 useful. If that became the way things worked forever, then `#[repr(compact)]`
 types would be very difficult to use, as almost no generic functions would
 accept them. Very few functions *actually* need `AlignSized`, but every generic
 function would get it implicitly.

 We could change this at an edition boundary: a later edition could drop the
 implicit `AlignSized` bound on all generics, and automated migration tooling
 could remove the implicit bound from any generic function which doesn't use the
 bound, and add an explicit bound for everything that does. After enough
 iterations, the only code with a bound on `AlignSized` would be code which
 transmutes between `T` and `[T]`/`[T; 1]`. Though this would be a disruptive and
 long migration.

 Alternatively, we could simply live with `repr(compact)` types being difficult
 and usually not usable in generic code. They would still be useful in
 non-generic code, and in cross-language interop.

 ### `alloc::Layout`

 `std::alloc::Layout` might not work as is. Consider the following function:

 ```rs
 fn make_c_struct() -> Layout {
     Layout::from_size_align(0, 1)?
         .extend(Layout::new::<T1>())?.0
         .extend(Layout::new::<T2>())?.0
         .pad_to_align()
 }
 ```

 This function was intended to return a `Layout` that is interchangeable with
 this Rust struct:

 ```rs
 #[repr(C)]
 struct S {
   x: T1,
   y: T2,
 }
 ```

 In order for this to continue returning the same `Layout`, it must work the same
 even if `T1` is changed to be `repr(compact)`. In other words, if `Layout::new`
 is to accept `?AlignSized` types, it must use the stride as the size. The same
 applies to `for_value*`.

 (Alternatively, it may be okay to reject non-`AlignSized` types.)

 One assumes, then, that we need `*_compact` versions of all the layout
 functions, which use data size instead of stride. And then:

 ```rs
 fn make_c_struct() -> Layout {
     Layout::from_size_align(0, 1)?
         .extend(Layout::new_compact::<T1>())?.0
         .extend(Layout::new::<T2>())?.0
         .pad_to_align()
 }
 ```

 Would generate the same `Layout` as for the following struct:

 ```rs
 #[repr(C)]
 struct S {
   #[compact] x: T1,
   y: T2,
 }
 ```

 Alternatively, perhaps we could introduce separated `data_size` and `stride`
 fields into the `Layout`, and have `extend` and `extend_compact`, supplementing
 `from_size_align(stride, align)` with `from_data_size_stride_align(data_size,
 stride, align)`.

 ... but this author is very interested to hear opinions about how this should
 all work out.

 ### It's yet another (implicit) size/alignment trait

 There is also some desire for
 [an `Aligned` trait](https://internals.rust-lang.org/t/aligned-trait/17443) or
 [a `DynSized` trait](https://github.com/rust-lang/rust/issues/43467#issuecomment-317733674).
 This would be yet another one, which may require changes throughout the Rust
 standard library and ecosystem to support everywhere one would ideally hope.

 ## Rationale and alternatives

 ### Alternative: manual layout

 One could in theory do it all by hand.

 #### User-defined padding-less references

 Instead of references, one could use `Pin`-like smart pointer types which
 forbids direct writes and reads. To avoid aliasing UB, this cannot actually be
 `Pin<&mut T>` etc. -- it must be a (wrapper around a) raw pointer, as one must
 never actually hold a `&mut T` or even a `&T`. This must be done for *all* Swift
 or C++ types which contain (what Rust would consider) tail padding, unless it is
 specifically known that they are held in an array, where it's safe to use Rust
 references.

 Something like this:

 ```rs
 struct PadlessRefMut<'a, T>(*mut T, PhantomData<&'a mut T>);
 ```

 Unfortunately, today, a generic type like `PadlessRefMut` is difficult to use:
 you cannot use it as a `self` type for methods, for instance, though
 [there are workarounds](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Extending.20.60arbitrary_self_types.60.20with.20.60UnsafeDeref.60).

 Even there, various bits of the Rust ecosystem expect references: for instance,
 you can't return a `PadlessRef` or `PadlessRefMut` from an `Index` or `IndexMut`
 implementation. This, too, could be fixed by replacing the indexing traits (and
 everything else with similar APIs) with a more general trait that uses GATs...
 but we can see already that, at least right now, this type would be quite
 unpleasant.

 #### Layout

 For emulating the layout rules of Swift and C++, you could manually lay out
 structs (e.g. via a proc macro) and use the same `Pin`-like pointer type:

 ```rs
 // instead of C++:
 //     `struct Foo {[[no_unique_address]] T1 x; [[no_unique_address]] T2 y; }`
 ##[repr(C, align( /* max(align_of<T1>(), align_of<T2>()) */ ... ))]
 struct Foo {
     // These arrays are not of size size_of<T1>() etc., but rather the same as the proposed data_size_of<T1>().
     x: [u8; SIZE_OF_T1_DATA],
     y: [u8; SIZE_OF_T2_DATA],
 }

 impl Foo {
     fn x_mut(&mut self) -> PadlessRefMut<'_, T1> {
         PadlessRefMut::new((&mut self.x).as_mut_ptr() as *mut _)
     }
     // etc.
 }
 ```

 This is especially easy to do when writing a bindings generator, since you can
 automatically query the other language's to find the struct layout, and
 automatically generate the corresponding Rust.) But otherwise, it's quite a
 pain -- one would hope, perhaps, for a proc macro to automate this, similar to
 how Rust automatically infers layout for paddingful structs and types.

 #### Conclusion: manual layout is unpleasant

 Almost nothing is impossible in Rust, including this. But it does mean virtually
 abandoning Rust in a practical sense: Rust's references cannot exclude tail
 padding, so we use raw pointers instead. Rust's layout rules cannot omit
 padding, and so we replace the layout algorithm with a pile of manually placed
 `u8` arrays and manually specified alignment. And the result integrates poorly
 with the rest of the Rust ecosystem, where most things expect conventional
 references, and things that don't or can't use references are difficult to work
 with.

 ### Alternative: `repr(packed)`, but with aligned fields

 We could replicate the layout of C++ and Swift structs, but make them very
 unsafe to use, similar to `repr(packed)`. One would still, like `repr(packed)`,
 avoid taking or using references to fields inside such structs, and these are
 still going to be difficult to work with as a result.

 ## Prior art

 ### Languages with this feature

 **Swift:** Swift implicitly employs this layout strategy for all types and all
 fields. A type has three size-related properties: its "size", meaning the
 literal size taken up by its field, not including padding; its "stride", meaning
 the difference between addresses of consecutive elements in an array; and its
 alignment.

 **C++:** Unlike Swift, C++ does not separate out size and stride into separate
 concepts. Instead, it claims that array stride and size are the same thing, as
 they are in Rust and C, but that objects can live inside the tail padding of
 other objects and that you are simply mutably aliasing into the tail padding in
 a way which the language defines the behavior for. C++ nominally allows this for
 the tail padding of all types, but only when they are stored in certain places:
 objects may be placed inside the tail padding of the previous object when that
 previous object is a subobject in the same struct (not, for instance, a separate
 local variable), and it is either a base class subobject (so-called "EBO"), or a
 `[[no_unique_address]]` data member ("field"). In practice, however, the
 compiler is free to not reuse the tail padding for some types. In the
 [Itanium ABI](https://itanium-cxx-abi.github.io/cxx-abi/abi.html), C-like
 structs ("POD" types, with
 [an Itanium-ABI-specific definition of "POD"](https://itanium-cxx-abi.github.io/cxx-abi/abi.html#POD))
 do not allow their tail padding to be reused.

 ### Papers and blog posts

 *   I worked around this in Crubit, a C++/Rust bindings generator. The design is
     here: https://github.com/google/crubit/blob/main/docs/unpin.md . tl;dr: if
     we assume that the only source of this layout phenomenon is base classes,
     then only non-`final` classes needed to get the uncomfortable `Pin`-like
     API. Unfortunately, this does not work if `[[no_unique_address]]` becomes
     pervasive.

 ## Unresolved questions

 -   What do we do about `std::alloc::Layout`?
 -   What's the long term future of the `AlignSized` bound?
 -   Clearly, for compatibility reasons if nothing else, Rust types must not have
     reusable tail padding unless specially marked. But what about fields: should
     it be opt-in per field (like C++), or automatic (like Swift)? In this doc,
     it's assumed to be opt-in per field for `repr(C)` (for C++-compatibility),
     and automatic for `repr(Rust)`.
 -   How free should Rust be to represent fields compactly in `repr(Rust)` types?
 -   Is `repr(C)` allowed to use this new layout strategy with specially marked
     fields using a new attribute, or do we need a new `repr`? The documentation
     is
     [very prescriptive](https://doc.rust-lang.org/std/mem/fn.size_of.html#size-of-reprc-items).
 -   This is part of a family of issues with interop, where Rust reference
     semantics do not match other languages' reference semantics. (The other
     prominent member of the family is "aliasing".) Part of the reason for
     wanting to use Rust references is simply the raw ergonomics: generic APIs
     take and return `&T`, self types requires `Deref` (which requires
     reference-compatible semantics), etc. It is worth asking: rather than
     modifying references, does this cross the line to where we should instead
     make it more pleasant to use pointers that cannot safely deref?
 -   "Language lawyering": how does this interact with existing features? For
     example, is a `repr(transparent)` type also `repr(compact)`? (I *believe*
     the answer should be yes.)
 -   TODO: better names for everything. For example, `repr(compact)`, "data size"
     and `data_size_of`. `AlignSized` especially.
 -   How much of the standard library should be updated to `?AlignSized`?
	# [Pre-RFC] Allow stride != size

	## Summary

	Rust should allow for values to be placed at the next aligned position after the
	previous value, ignoring the tail padding of that previous field. This requires
	changing the meaning of "size", so that a value's size in memory (for the
	purpose of reference semantics and layout) is not definitionally the same as the
	distance between consecutive values of that type (its "stride").

	## Motivation

	Some other languages (C++ and Swift, in particular) can lay out values more
	compactly than Rust conventionally can, leading to better performance at greater
	convenience, and less than ideal Rust interoperability.

	### Optimization opportunity

	Consider the difference between `(u16, u8, u8)` and `((u16, u8), u8)`. The first
	can fit in 4 bytes, while the second requires 6. A `(u16, u8)` is a 4 byte value
	with 1 byte of tail padding. And a `(T, u8)` can't just stuff the `u8` inside
	the tail padding for `T`! If, instead, we declared that `(u16, u8)` were a 3
	byte value with alignment 2, then `((u16, u8), u8)` could be 4 bytes instead of
	6. This is not possible today.

	(For backwards compatibility reasons described later, we can't literally do this
	for tuples, but only for user-defined types. But this gives the gist of the
	optimization opportunity this proposal supports.)

	By inventing the concept of a "data size", which doesn't need to be a multiple
	of the alignment, we can allow fields in specially-designed types to be packed
	closer together than they would be today, saving space. This is similar to the
	performance benefits of `#[repr(packed)]`, but safer: all values would still be
	correctly aligned, just placed more closely together.

	This optimization has already been implemented in other programming languages.
	Swift applies this to every type and every field: a type's size excludes tail
	padding, and a neighboring value can be laid out immediately next to it when
	stored in the same type, with no padding between the two. In C++, the
	optimization automatically applies to base classes
	(["EBO"](https://en.cppreference.com/w/cpp/language/ebo), the Empty Base
	Optimization), and is opt-in on fields via the
	[`[[no_unique_address]]`](https://en.cppreference.com/w/cpp/language/attributes/no_unique_address)
	attribute.

	For example, here's an example in [Swift](https://godbolt.org/z/G74ejjsvc) and
	in [C++](https://godbolt.org/z/4esbYrv39). These types are compact! Rust does
	not work like this today.

	### Interoperability with C++ and Swift

	(Note that the author works on C++ interop, Swift is mentioned for
	completeness.)

	In fact, exactly because this optimization is already implemented in other
	languages, those languages are theoretically not as compatible with Rust as they
	are with each other. In C++ and Swift, writing to a pointer or reference does
	not write to neighboring fields. But if that pointer or reference were passed to
	Rust, and you used any Rust facility to write to it -- whether it were vanilla
	assignment or `ptr::write` -- Rust could overwrite that neighboring field.
	Because the use of this optimization is pervasive in both Swift and C++,
	interoperating with these languages is difficult to do safely.

	Concretely, consider the following C++ struct:

	```c++
	struct MyStruct {
	[[no_unique_address]] T1 x;
	[[no_unique_address]] T2 y;
	...
	};
	```

	Which is equivalent to this Swift struct:

	```swift
	struct MyStruct {
	let x: T1
	let y: T2
	...
	}
	```

	If you are working with cross-language interop, and obtain in Rust a `&mut T1`
	which refers to `x`, and a `&mut T2` which refers to `y`, it may be immediately
	UB, because these references can overlap in Rust: `y` may be located inside what
	Rust would consider the tail padding of the `T1` reference.

	For the same reason, even if you avoid aliasing, if you obtain a `&mut T1` for
	`x`, and then write to it, it may partially overwrite `y` with garbage data,
	causing unexpected or undefined behavior down the line.

	This also cannot be avoided by forbidding the use of `MyStruct`: even if you do
	not directly use it from Rust, from the point of view of Swift and C++, it is
	just a normal struct, and Swift and C++ codebases can freely pass around
	references and pointers to its interior. Someone passing a reference to a `T1`
	may have no idea whether it came from `MyStruct` (unsafe to pass to Rust) or an
	array (safe). You would need to ban (or correctly handle) any C++ and Swift type
	which can have tail padding, in case that padding contains another object.

	(To add insult to injury, the struct `MyStruct` itself -- not just references to
	fields inside it -- cannot be represented directly as so in Rust, either.)

	And anyway, such structs are unavoidable. In Swift, this is the default
	behavior, and pervasive. In C++, `[[no_unique_address]]` is permitted to be used
	pervasively in the standard library, and it is impractical to only interoperate
	with C++ codebases that avoid the standard library.

	In order for C++ and Swift pointers/references to be safely representable in
	Rust as mut references, a `&mut T1` would need to exclude the tail padding,
	which means that Rust would need to separate out the concept of a type's
	interior size from its array stride. And in order to represent `MyStruct` in
	Rust, we would need a way to use the same layout rules that are available in
	these other languages.

	## Explanation

	(I haven't separated this out to guide-level vs reference-level -- this is a
	pre-RFC! Also, all names TBD.)

	As a quick summary, the proposal is to introduce the following new traits,
	functions, and attributes, and behaviors:

	* `std::mem::data_size_of<T>()`, returning the size but not necessarily
	rounded to alignment / not necessarily the same as stride.
	* In the memory model, pointers and references only refer to
	`data_size_of::<T>()` bytes.
	* `AlignSized`, a trait for types where the data size and stride are the same.
	* `#[repr(compact)]`, to mark a type as not implementing `AlignSized`, and
	thus having a potentially smaller data size.
	* `#[compact]`, to mark a field as laid out using the data size instead of the
	stride.

	## Data size vs stride

	Semantically, Rust types would gain a new kind of size: "data size". This is the
	size of the type, minus the tail padding. In fact, it's in some sense the "true"
	size of the type: array stride is the data size rounded up to alignment.

	Data size would be exposed via a new function `std::mem::data_size_of::<T>()`;
	array stride continues to be returned by `std::mem::size_of::<T>()`.

	The semantics of a write (e.g. via `ptr::write`, `mem::swap`, or assignment) are
	to only write "data size" number of bytes, and a `&T` or `&mut T` would only
	refer to "data size" number of bytes for the purpose of provenance and aliasing
	semantics. (`&[T; 1]`, in contrast, continues to refer to `size_of::<T>()`
	bytes.)

	## The `AlignSized` trait and `std::array::from_ref`

	It is fundamentally a backwards-incompatible change to make stride and size not
	the same thing, because of functions like
	[`std::array::from_ref`](https://doc.rust-lang.org/stable/std/array/fn.from_ref.html)
	and
	[`std::slice::from_ref`](https://doc.rust-lang.org/stable/std/slice/fn.from_ref.html).
	The existence of these functions means that Rust guarantees that for an
	arbitrary generic type today, that type has identical size and stride.

	This means that if we want to allow for data size and stride to be different,
	they must not be different for any generic type as written today. Existing code
	without trait bounds can call `from_ref`! So we must add an implicit trait bound
	on `AlignSized : Sized`, which, like `Sized`, guarantees that the data size and
	the stride are the same. This trait would be automatically implemented for all
	pre-existing types, which retain their current layout rules.

	In other words, the following two generics are equivalent:

	```rs
	fn foo<T>() {}
	fn foo<T: Sized + AlignSized>() {}
	```

	... and to opt out of requiring `AlignSized`, one must explicitly remove a trait
	bound:

	```rs
	fn foo2<T: ?AlignSized>() {}
	// AlignSized requires Sized, and so this will also do it:
	fn foo3<T: ?Sized>() {}
	```

	To opt out of implementing this trait, and to opt in to being placed closer to
	neighboring types inside a compound data structure, types can mark themselves as
	`#[repr(compact)]`. This causes the data size not to be rounded up to alignment:

	```rs
	#[repr(C, compact)]
	struct MyCompactType(u16, u8);
	// data_size_of::<MyCompactType>() == 3
	// size_of::<MyCompactType>() == 4
	```

	## Taking advantage of non-`AlignSized` types with `#[compact]` storage

	If a field is marked `#[compact]`, then the next field is placed after the data
	size of that field, not after the stride. (These can only differ for a
	non-`AlignSized` type.) This provides easy control, and provides compatibility
	with C++, where this behavior can be configured per-field.

	It is an error to apply this attribute on non-`#[repr(C)]` types.

	```rs
	#[repr(C, compact)]
	struct MyCompactType(u16, u8);

	#[repr(C)]
	struct S {
	#[compact]
	a: MyCompactType, // occupies the first 3 bytes
	b: u8, // occupies the 4th byte
	}
	// data_size_of::<S>() == size_of::<S>() == 4
	```

	## Example

	Putting everything together:

	```rs
	#[repr(C, compact)]
	struct MyCompactType(u16, u8);
	// data_size_of::<MyCompactType>() == 3
	// size_of::<MyCompactType>() == 4

	#[repr(C)]
	struct S {
	#[compact]
	a: MyCompactType, // occupies the first 3 bytes
	b: u8, // occupies the 4th byte
	}

	// data_size_of::<S>() == size_of::<S>() == 4
	```

	We can take `mut` references to both fields `a` and `b`, and writes to those
	references will not overlap:

	```rs
	let mut x : S = ...;
	let S {a, b} = &mut x;
	*a = MyCompactType(4, 2); // writes 3 bytes
	*b = 0; // writes 1 byte
	```

	If we had not applied the `repr(compact)` attribute, or had not applied the
	`#[compact]` attribute, then `data_size_of<S>()` would have been 6, and so would
	`size_of<S>()`. The assignment `*a = ...` would have (potentially) written 4
	bytes.

	## Drawbacks

	### Backwards compatibility and the `AlignSized` trait

	In order to be backwards compatible, this change requires a new implicit trait
	bound, applied everywhere. However, that makes this change substantially less
	useful. If that became the way things worked forever, then `#[repr(compact)]`
	types would be very difficult to use, as almost no generic functions would
	accept them. Very few functions actually need `AlignSized`, but every generic
	function would get it implicitly.

	We could change this at an edition boundary: a later edition could drop the
	implicit `AlignSized` bound on all generics, and automated migration tooling
	could remove the implicit bound from any generic function which doesn't use the
	bound, and add an explicit bound for everything that does. After enough
	iterations, the only code with a bound on `AlignSized` would be code which
	transmutes between `T` and `[T]`/`[T; 1]`. Though this would be a disruptive and
	long migration.

	Alternatively, we could simply live with `repr(compact)` types being difficult
	and usually not usable in generic code. They would still be useful in
	non-generic code, and in cross-language interop.

	### `alloc::Layout`

	`std::alloc::Layout` might not work as is. Consider the following function:

	```rs
	fn make_c_struct() -> Layout {
	Layout::from_size_align(0, 1)?
	.extend(Layout::new::<T1>())?.0
	.extend(Layout::new::<T2>())?.0
	.pad_to_align()
	}
	```

	This function was intended to return a `Layout` that is interchangeable with
	this Rust struct:

	```rs
	#[repr(C)]
	struct S {
	x: T1,
	y: T2,
	}
	```

	In order for this to continue returning the same `Layout`, it must work the same
	even if `T1` is changed to be `repr(compact)`. In other words, if `Layout::new`
	is to accept `?AlignSized` types, it must use the stride as the size. The same
	applies to `for_value*`.

	(Alternatively, it may be okay to reject non-`AlignSized` types.)

	One assumes, then, that we need `*_compact` versions of all the layout
	functions, which use data size instead of stride. And then:

	```rs
	fn make_c_struct() -> Layout {
	Layout::from_size_align(0, 1)?
	.extend(Layout::new_compact::<T1>())?.0
	.extend(Layout::new::<T2>())?.0
	.pad_to_align()
	}
	```

	Would generate the same `Layout` as for the following struct:

	```rs
	#[repr(C)]
	struct S {
	#[compact] x: T1,
	y: T2,
	}
	```

	Alternatively, perhaps we could introduce separated `data_size` and `stride`
	fields into the `Layout`, and have `extend` and `extend_compact`, supplementing
	`from_size_align(stride, align)` with `from_data_size_stride_align(data_size,
	stride, align)`.

	... but this author is very interested to hear opinions about how this should
	all work out.

	### It's yet another (implicit) size/alignment trait

	There is also some desire for
	[an `Aligned` trait](https://internals.rust-lang.org/t/aligned-trait/17443) or
	[a `DynSized` trait](https://github.com/rust-lang/rust/issues/43467#issuecomment-317733674).
	This would be yet another one, which may require changes throughout the Rust
	standard library and ecosystem to support everywhere one would ideally hope.

	## Rationale and alternatives

	### Alternative: manual layout

	One could in theory do it all by hand.

	#### User-defined padding-less references

	Instead of references, one could use `Pin`-like smart pointer types which
	forbids direct writes and reads. To avoid aliasing UB, this cannot actually be
	`Pin<&mut T>` etc. -- it must be a (wrapper around a) raw pointer, as one must
	never actually hold a `&mut T` or even a `&T`. This must be done for all Swift
	or C++ types which contain (what Rust would consider) tail padding, unless it is
	specifically known that they are held in an array, where it's safe to use Rust
	references.

	Something like this:

	```rs
	struct PadlessRefMut<'a, T>(*mut T, PhantomData<&'a mut T>);
	```

	Unfortunately, today, a generic type like `PadlessRefMut` is difficult to use:
	you cannot use it as a `self` type for methods, for instance, though
	[there are workarounds](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Extending.20.60arbitrary_self_types.60.20with.20.60UnsafeDeref.60).

	Even there, various bits of the Rust ecosystem expect references: for instance,
	you can't return a `PadlessRef` or `PadlessRefMut` from an `Index` or `IndexMut`
	implementation. This, too, could be fixed by replacing the indexing traits (and
	everything else with similar APIs) with a more general trait that uses GATs...
	but we can see already that, at least right now, this type would be quite
	unpleasant.

	#### Layout

	For emulating the layout rules of Swift and C++, you could manually lay out
	structs (e.g. via a proc macro) and use the same `Pin`-like pointer type:

	```rs
	// instead of C++:
	// `struct Foo {[[no_unique_address]] T1 x; [[no_unique_address]] T2 y; }`
	##[repr(C, align( /* max(align_of<T1>(), align_of<T2>()) */ ... ))]
	struct Foo {
	// These arrays are not of size size_of<T1>() etc., but rather the same as the proposed data_size_of<T1>().
	x: [u8; SIZE_OF_T1_DATA],
	y: [u8; SIZE_OF_T2_DATA],
	}

	impl Foo {
	fn x_mut(&mut self) -> PadlessRefMut<'_, T1> {
	PadlessRefMut::new((&mut self.x).as_mut_ptr() as *mut _)
	}
	// etc.
	}
	```

	This is especially easy to do when writing a bindings generator, since you can
	automatically query the other language's to find the struct layout, and
	automatically generate the corresponding Rust.) But otherwise, it's quite a
	pain -- one would hope, perhaps, for a proc macro to automate this, similar to
	how Rust automatically infers layout for paddingful structs and types.

	#### Conclusion: manual layout is unpleasant

	Almost nothing is impossible in Rust, including this. But it does mean virtually
	abandoning Rust in a practical sense: Rust's references cannot exclude tail
	padding, so we use raw pointers instead. Rust's layout rules cannot omit
	padding, and so we replace the layout algorithm with a pile of manually placed
	`u8` arrays and manually specified alignment. And the result integrates poorly
	with the rest of the Rust ecosystem, where most things expect conventional
	references, and things that don't or can't use references are difficult to work
	with.

	### Alternative: `repr(packed)`, but with aligned fields

	We could replicate the layout of C++ and Swift structs, but make them very
	unsafe to use, similar to `repr(packed)`. One would still, like `repr(packed)`,
	avoid taking or using references to fields inside such structs, and these are
	still going to be difficult to work with as a result.

	## Prior art

	### Languages with this feature

	Swift: Swift implicitly employs this layout strategy for all types and all
	fields. A type has three size-related properties: its "size", meaning the
	literal size taken up by its field, not including padding; its "stride", meaning
	the difference between addresses of consecutive elements in an array; and its
	alignment.

	C++: Unlike Swift, C++ does not separate out size and stride into separate
	concepts. Instead, it claims that array stride and size are the same thing, as
	they are in Rust and C, but that objects can live inside the tail padding of
	other objects and that you are simply mutably aliasing into the tail padding in
	a way which the language defines the behavior for. C++ nominally allows this for
	the tail padding of all types, but only when they are stored in certain places:
	objects may be placed inside the tail padding of the previous object when that
	previous object is a subobject in the same struct (not, for instance, a separate
	local variable), and it is either a base class subobject (so-called "EBO"), or a
	`[[no_unique_address]]` data member ("field"). In practice, however, the
	compiler is free to not reuse the tail padding for some types. In the
	[Itanium ABI](https://itanium-cxx-abi.github.io/cxx-abi/abi.html), C-like
	structs ("POD" types, with
	[an Itanium-ABI-specific definition of "POD"](https://itanium-cxx-abi.github.io/cxx-abi/abi.html#POD))
	do not allow their tail padding to be reused.

	### Papers and blog posts

	* I worked around this in Crubit, a C++/Rust bindings generator. The design is
	here: https://github.com/google/crubit/blob/main/docs/unpin.md . tl;dr: if
	we assume that the only source of this layout phenomenon is base classes,
	then only non-`final` classes needed to get the uncomfortable `Pin`-like
	API. Unfortunately, this does not work if `[[no_unique_address]]` becomes
	pervasive.

	## Unresolved questions

	- What do we do about `std::alloc::Layout`?
	- What's the long term future of the `AlignSized` bound?
	- Clearly, for compatibility reasons if nothing else, Rust types must not have
	reusable tail padding unless specially marked. But what about fields: should
	it be opt-in per field (like C++), or automatic (like Swift)? In this doc,
	it's assumed to be opt-in per field for `repr(C)` (for C++-compatibility),
	and automatic for `repr(Rust)`.
	- How free should Rust be to represent fields compactly in `repr(Rust)` types?
	- Is `repr(C)` allowed to use this new layout strategy with specially marked
	fields using a new attribute, or do we need a new `repr`? The documentation
	is
	[very prescriptive](https://doc.rust-lang.org/std/mem/fn.size_of.html#size-of-reprc-items).
	- This is part of a family of issues with interop, where Rust reference
	semantics do not match other languages' reference semantics. (The other
	prominent member of the family is "aliasing".) Part of the reason for
	wanting to use Rust references is simply the raw ergonomics: generic APIs
	take and return `&T`, self types requires `Deref` (which requires
	reference-compatible semantics), etc. It is worth asking: rather than
	modifying references, does this cross the line to where we should instead
	make it more pleasant to use pointers that cannot safely deref?
	- "Language lawyering": how does this interact with existing features? For
	example, is a `repr(transparent)` type also `repr(compact)`? (I believe
	the answer should be yes.)
	- TODO: better names for everything. For example, `repr(compact)`, "data size"
	and `data_size_of`. `AlignSized` especially.
	- How much of the standard library should be updated to `?AlignSized`?