Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@sirati
Copy link

@sirati sirati commented Oct 19, 2025

Motivation

I wanted to use musli with garde for field validation, however due to coherence its not possible to add blanket impl for Valid and Unvalidated and I would like to avoid requiring newtyping them.

Content

All this PR does is

impl<TValid, M> Encode<M> for Valid<TValid>
where
    TValid: Validate + Encode<M>{...}
    
impl<'de, TValid, M, A> Decode<'de, M, A> for Unvalidated<TValid>
where
    TValid: Validate + Decode<'de, M, A>,
    A: Allocator {...}
    
impl<'de, TValid, M, A> Decode<'de, M, A> for Valid<TValid>
where
    TValid: Validate<Context: Default> + Decode<'de, M, A>,
    A: Allocator {...}

here Decode for Valid automatically also validates.

Other consideration

  1. It would make sense to extend the macro with an option so that Decode is not impl for TValid but only for Unvalidated<TValid> and Valid<TValid> to make it impossible to accidentally directly decode a type skipping validation, but this would require changing the macro to be able to handle feature specific special cases.

  2. It would also be possible to not impl Decode for Valid and always force manual calls to validate(). This is always the case for types that do not have a default Validation context. it may even be possible to link validation context to musli's context

Todos

  1. In the branch for this commit I have not incremented crate version numbers. (done in fork's main branch)
  2. no tests were added

@sirati sirati changed the title Add feature garde Add feature garde to support blanked impl for garde crate Oct 19, 2025
@udoprog udoprog added the enhancement New feature or request label Oct 21, 2025
@udoprog
Copy link
Owner

udoprog commented Oct 21, 2025

Cheers.

FYI, since garde has serde impls and (this implementation doesn't look specialized) you likely could use the available serde integration.

I am not psyched about adding impls here so I will have to think this over. But, at least the feature flag needs to include the "major version" of garde, which assuming they follow semver would be garde022.

The modules also do not need to be public and should be named garde022 as well.

@sirati
Copy link
Author

sirati commented Oct 27, 2025

I am primarily using musli because I did not want to use serde, that's why I would have it rather provide an implementation. Further, I use it on my own types, which would require me to either derive Serde on them or to adapt musli->serde->garde->musli-serde->musli which defeats the point. I can life without it being merged, then I will just have to maintain a local fork.

With the feature being version bound I would also expect that it does not add any maintenance burden unless musli changed the public facing API. I am happy to be responsible for this feature.

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.

2 participants