Skip to content

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Aug 30, 2025

This removes the non_exhaustive attribute from the Book and its inner types BookItem and Chapter. These were added in #2779. After thinking about it more, I realized that these types cannot be extended in a semver-compatible way, so I am fine with allowing them be exhaustive.

The problem is that with CmdPreprocessor, the Book will be re-serialized by a preprocessor, which could potentially be on an older version. Attempting to add any new fields/variants means that either the deserialization will fail, or the new fields will be stripped by the preprocessor.

These could potentially be structured such that they have a serde(flatten) or Other/Unknown variant so that a preprocessor would at least see the extra fields/variants and pass them along back to the output. However, a preprocessor or renderer wouldn't know what to do with those new fields/variants (particularly BookItem) which would itself be a problem. It's still possible to do something like this in the future, but for now I think it's fine to restrict these to semver-major changes.

This removes the `non_exhaustive` attribute from the `Book` and its
inner types `BookItem` and `Chapter`. These were added in
rust-lang#2779. After thinking about it
more, I realized that these types cannot be extended in a
semver-compatible way, so I am fine with allowing them be exhaustive.

The problem is that with CmdPreprocessor, the `Book` will be
re-serialized by a preprocessor, which could potentially be on an older
version. Attempting to add any new fields/variants means that either the
deserialization will fail, or the new fields will be stripped by the
preprocessor.

These could potentially be structured such that they have a
`serde(flatten)` or Other/Unknown variant so that a preprocessor would
at least see the extra fields/variants and pass them along back to the
output. However, a preprocessor or renderer wouldn't know what to do
with those new fields/variants (particularly `BookItem`) which would
itself be a problem. It's still possible to do something like this in
the future, but for now I think it's fine to restrict these to
semver-major changes.
@rustbot rustbot added the S-waiting-on-review Status: waiting on a review label Aug 30, 2025
@ehuss ehuss enabled auto-merge August 30, 2025 01:26
@ehuss ehuss added this pull request to the merge queue Aug 30, 2025
Merged via the queue into rust-lang:master with commit be63b44 Aug 30, 2025
14 checks passed
@rustbot rustbot removed the S-waiting-on-review Status: waiting on a review label Aug 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants