Skip to content

Conversation

@tcharding
Copy link
Member

Improve all the decoders and decoder error types in units. Based on recent discussion.

This PR introduces policy on how we implement decoder error types (patch 1 and 2).

LFG, decoders done by Nashville!

@tcharding tcharding added the policy Contains discussion on policy label Sep 24, 2025
@github-actions github-actions bot added the C-units PRs modifying the units crate label Sep 24, 2025
@tcharding
Copy link
Member Author

cc @nyonson, I know you are watching but just to be sure.

@tcharding tcharding changed the title units: Improve the decoding logic units: Improve the decoders Sep 24, 2025
}

#[cfg(feature = "encoding")]
impl From<encoding::UnexpectedEofError> for AmountDecoderError {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New pattern for me here so might be missing something, but would this From impl still be useful if updates to the new constructor?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for removing this is that if we keep it we have to commit to it, so we cannot stop using the UnexpectedEofError. As much as this is unlikely I'm trying to be as conservative as possible and since the from impl is only used internally there is no need for it other than ergonomics (in internal code). Also downstream should never be constructing AmountDecoderError.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, thanks for the explanation. Wasn't obvious to me how the From was part of the exported API.

Introduces new policy on how we implement decoder error types.

- All internals are hidden
- No `From<OtherError>` impls
- Private constructors 
- Inner enum is private (does not need non_exhaustive).
If two encoders return the same error it is not currently possible to
compose them with our decoders. Having a new type instead of returning
the `UnexpectedEofError` makes this possible (assuming one doesn't
want to compose two decoders of the same type).
So the decoders can be used by downstream add constructors for them
all. Also implement `Default` for the decoder types.
As we do for other `signed` and `unsigned` types; re-export the
`AmountDecoder` from the `amount` module.
@apoelstra
Copy link
Member

You need another API run after the last commit.

@apoelstra
Copy link
Member

But utACK 6175586

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK b8af0d7; successfully ran local tests

@apoelstra apoelstra merged commit 9b90283 into rust-bitcoin:master Sep 26, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

C-units PRs modifying the units crate policy Contains discussion on policy

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants