You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/frequently-requested-changes.md
+9-4Lines changed: 9 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -182,9 +182,9 @@ condition before the return expression).
182
182
## Size != Stride
183
183
184
184
Rust assumes that the size of an object is equivalent to the stride of an object -
185
-
this means that the size of `[T; N]` is `N * std::mem::size_of::<T>`. Other languages
186
-
may have objects that take up less space in arrays due to the reuse of tail
187
-
padding, and allow interop with other languages which do this optimization.
185
+
this means that the size of `[T; N]` is `N * std::mem::size_of::<T>`. Allowing
186
+
size to not equal stride may allow objects that take up less space in arrays due
187
+
to the reuse of tail padding, and allow interop with other languages with this behavior.
188
188
189
189
One downside of this assumption is that types with alignment greater than their size can
190
190
waste large amounts of space due to padding. An overaligned struct such as the following:
@@ -205,7 +205,12 @@ can be manually offset by the size of the type to access the next array element.
205
205
code may also assume that overwriting trailing padding is allowed, which would conflict with
206
206
the repurposing of such padding for data storage.
207
207
208
-
While changing the fundamental layout guarantees seems unlikely, it may be reasonable to add additional inspection APIs for code that wishes to opt into the possibility of copying smaller parts of an object -- an API to find out that copying only bytes `0..1` of `Overaligned` is sufficient might still be reasonable, or something `size_of_val`-like that could be variant-aware to say which bytes are sufficient for copying a particular instance.
208
+
While changing the fundamental layout guarantees seems unlikely, it may be reasonable to add additional
209
+
inspection APIs for code that wishes to opt into the possibility of copying smaller parts of an object
210
+
-- an API to find out that copying only bytes `0..1` of `Overaligned` is sufficient might still be
211
+
reasonable, or something `size_of_val`-like that could be variant-aware to say which bytes are sufficient
212
+
for copying a particular instance. Similarly, move-only fields may allow users to mitigate the effects
213
+
of tail or internal padding, as they can be reused due to the lack of a possible reference or pointer.
0 commit comments