Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add decode_any through Visitor #11

Merged
merged 1 commit into from
May 16, 2023
Merged

Add decode_any through Visitor #11

merged 1 commit into from
May 16, 2023

Conversation

udoprog
Copy link
Owner

@udoprog udoprog commented May 16, 2023

This is the last missing API piece I can think of:

A thing decoding might want to ask the decoder if it knows what type is being decoded.

Previously this was handled through Decoder::type_hint, but this has a runtime penalty: The returned TypeHint needs to be matched over.

Instead for this we adopt a modified Visitor pattern from serde, the twist being that the visitor can produce its own sub-visitors: type String, type Bytes and type Number. This makes visitors more composable since it's a more granular set of traits you need to implement and use instead of one big Visitor trait.

The #[musli::visitor] attribute also has to be added to allow for API evolution.

This is what its use looks like in musli-value:

#[musli::visitor]
impl<'de, M, E> Visitor<'de> for AnyVisitor<M, E>
where
    M: Mode,
    E: Error,
{
    type Ok = Value;
    type Error = E;

    type String = StringVisitor<E>;
    type Bytes = BytesVisitor<E>;
    type Number = ValueNumberVisitor<E>;

    /* ... */
}

@udoprog udoprog added the enhancement New feature or request label May 16, 2023
@udoprog udoprog merged commit cd44b17 into main May 16, 2023
@udoprog udoprog deleted the visitor branch May 16, 2023 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant