Skip to content

Commit 851fd71

Browse files
committed
Updates from review from joshtriplett
1 parent dc59366 commit 851fd71

File tree

1 file changed

+12
-12
lines changed

1 file changed

+12
-12
lines changed

src/doc/src/reference/semver.md

+12-12
Original file line numberDiff line numberDiff line change
@@ -211,7 +211,7 @@ crates should be avoided.
211211
It is a breaking change to change the alignment, layout, or size of a type that was previously well-defined.
212212

213213
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.
215215

216216
> **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.
217217
> 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
225225
See [enum-variant-new](#enum-variant-new).
226226
* 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).
227227
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`.
229229
See [repr-c-enum-variant-new](#repr-c-enum-variant-new).
230230
* Adding `repr(C)` to a default representation struct, union, or enum.
231231
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
234234
* Adding `repr(transparent)` to a default representation struct or enum.
235235
See [repr-transparent-add](#repr-transparent-add).
236236

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.
238238

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:
240248

241249
* Adding `repr(packed)` to a struct or union.
242250
See [repr-packed-add](#repr-packed-add).
@@ -261,14 +269,6 @@ Some examples of a breaking change are:
261269
* Removing `repr(transparent)` from a struct or enum.
262270
See [repr-transparent-remove](#repr-transparent-remove).
263271

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.
270-
For example, see [`UnsafeCell`].
271-
272272
[the default representation]: ../../reference/type-layout.html#the-default-representation
273273
[primitive representation]: ../../reference/type-layout.html#primitive-representations
274274
[`repr` attribute]: ../../reference/type-layout.html#representations

0 commit comments

Comments
 (0)