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/doc/src/reference/semver.md
+12-12
Original file line number
Diff line number
Diff line change
@@ -211,7 +211,7 @@ crates should be avoided.
211
211
It is a breaking change to change the alignment, layout, or size of a type that was previously well-defined.
212
212
213
213
In general, types that use the [the default representation] do not have a well-defined alignment, layout, or size.
214
-
The compiler is free to alter the alignment, layout or size, so code should not make any assumptions about it.
214
+
The compiler is free to alter the alignment, layout, or size, so code should not make any assumptions about it.
215
215
216
216
> **Note**: It may be possible for external crates to break if they make assumptions about the alignment, layout, or size of a type even if it is not well-defined.
217
217
> This is not considered a SemVer breaking change since those assumptions should not be made.
@@ -225,7 +225,7 @@ Some examples of changes that are not a breaking change are (assuming no other r
225
225
See [enum-variant-new](#enum-variant-new).
226
226
* Adding, removing, reordering, or changing private fields of a `repr(C)` struct, union, or enum, following the other rules in this guide (for example, using `non_exhaustive`, or adding private fields when other private fields already exist).
227
227
See [repr-c-private-change](#repr-c-private-change).
228
-
* Adding variants to a `repr(C)` enum, if the enum uses `non_exhastive`.
228
+
* Adding variants to a `repr(C)` enum, if the enum uses `non_exhaustive`.
229
229
See [repr-c-enum-variant-new](#repr-c-enum-variant-new).
230
230
* Adding `repr(C)` to a default representation struct, union, or enum.
231
231
See [repr-c-add](#repr-c-add).
@@ -234,9 +234,17 @@ Some examples of changes that are not a breaking change are (assuming no other r
234
234
* Adding `repr(transparent)` to a default representation struct or enum.
235
235
See [repr-transparent-add](#repr-transparent-add).
236
236
237
-
Nominal types that use the [`repr` attribute] can be said to have an alignment and layout that is defined in some way that code may make some assumptions about that may break as a result of changing that type.
237
+
Types that use the [`repr` attribute] can be said to have an alignment and layout that is defined in some way that code may make some assumptions about that may break as a result of changing that type.
238
238
239
-
Some examples of a breaking change are:
239
+
In some cases, types with a `repr` attribute may not have an alignment, layout, or size that is well-defined.
240
+
In these cases, it may be safe to make changes to the types, though care should be exercised.
241
+
For example, types with private fields that do not otherwise document their alignment, layout, or size guarantees cannot be relied upon by external crates since the public API does not fully define the alignment, layout, or size of the type.
242
+
243
+
A common example where a type with *private* fields is well-defined is a type with a single private field with a generic type, using `repr(transparent)`,
244
+
and the prose of the documentation discusses that it is transparent to the generic type.
245
+
For example, see [`UnsafeCell`].
246
+
247
+
Some examples of breaking changes are:
240
248
241
249
* Adding `repr(packed)` to a struct or union.
242
250
See [repr-packed-add](#repr-packed-add).
@@ -261,14 +269,6 @@ Some examples of a breaking change are:
261
269
* Removing `repr(transparent)` from a struct or enum.
262
270
See [repr-transparent-remove](#repr-transparent-remove).
263
271
264
-
In some cases, types with a `repr` attribute may not have an alignment, layout, or size that is well-defined.
265
-
In these cases, it may be safe to make changes to the types, though care should be exercised.
266
-
For example, types with private fields that do not otherwise document their alignment, layout, or size guarantees cannot be relied upon by external crates since the public API does not fully define the alignment, layout, or size of the type.
267
-
268
-
A common example where a type with *private* fields is well-defined is a type with a single private field with a generic type, using `repr(transparent)`,
269
-
and the prose of the documentation discusses that it is transparent to the generic type.
0 commit comments