Skip to content

v0.18.0

Compare
Choose a tag to compare
@jprochazk jprochazk released this 28 Jan 12:17
· 47 commits to main since this release

There are quite a few changes in this release:

  • Length modes in #88
  • Adapters in #93
  • Remove default features, replace with full in #95
  • Serialize/deserialize Report in #90
  • Remove empty colon from display impl of Report in #91

Some of these are breaking changes. If you are only using the derive functionality and calling validate, updating should still be as simple as a version bump:

cargo add garde@0.18 -F full

If it isn't, please open an issue!

Length modes

You can now specify what kind of length you wish to validate by adding a new mode argument to your length rules. The argument is optional.

#[derive(garde::Validate)]
#[garde(transparent)]
struct Username(
    #[garde(
        length(bytes, min = 1, max = 100),
        length(graphemes, min = 1, max = 25)
    )]
    String
);

The above validates both bytes (via v.len()) and graphemes (via v.graphemes().count() using the unicode-segmentation crate. To understand why the distinction is important, consider the x̧̡̬̘͓̖̲̻̻̲̠̪̻͓͙̜̂̓̊̔̀̀͗̑̀̅̀̂̚͘̕̚͘͢͜͠ character, which occupies 73 bytes in memory, but is considered a single grapheme.

The available modes are:

  • simple, which is the default, and its behavior depends on the type. For strings, it measures the number of bytes, and for collections (such as Vec), it meaures the number of items.
  • bytes, which uses s.len(), measuring the number of bytes,
  • graphemes, which uses s.graphemes(true).count(), measuring the number of graphemes
  • chars, which uses s.chars().count(), measuring the number of unicode scalar values
  • utf16, which uses s.encode_utf16().count(), measuring the number of UTF-16 code units

The original Length and HasLength traits have been removed, and replaced by one trait per length mode.

Adapters

Using adapters, it is possible to implement validation rules for 3rd-party types directly in your own crates.

mod my_str_adapter {
    #![allow(unused_imports)]
    pub use garde::rules::*; // re-export garde's rules

    pub mod length {
        pub use garde::rules::length::*; // re-export `length` rules

        pub mod simple {
            // re-implement `simple`, but _only_ for the concrete type &str!
            pub fn apply(v: &str, (min, max): (usize, usize)) -> garde::Result {
                if !(min..=max).contains(&v.len()) {
                    Err(garde::Error::new("my custom error message"))
                } else {
                    Ok(())
                }
            }
        }
    }
}

Adapters are applied using the adapt field-level attribute:

#[derive(garde::Validate)]
struct Stuff<'a> {
    #[garde(
        adapt(my_str_adapter),
        length(min = 1),
        ascii,
    )]
    v: &'a str,
}

Now my_str_adapter::length::simple will be used instead of garde::rules::length::simple when validating the above type, removing the need for a newtype over str!

full feature

Having default features for a crate such as garde means that downstream users are more likely to end up with those default features in their lockfile with no way to turn them off, resulting in increased compile times in exchange for no benefit. Due to this, the default feature from garde has been removed, and we now have a new full feature which contains everything from the removed default feature.

To retain all the features previously in default, enable the full feature when you update:

cargo add garde@0.18 -F full

I urge you to consider if you really need all of full, though! There may be parts you're not using, and taking a few minutes to see what is the minimum feature set with which your project compiles is definitely worth it.

Miscellaneous

  • The Report type now has implementations of serde::Deserialize and serde::Serialize when the serde feature is enabled. Note that the implementation of Serialize has been updated to make it possible to implement a lossless serialize -> deserialize roundtrip, which is a breaking change if you were doing something with the serialized reports.

  • Validation errors on newtypes previously looked like this:

    : length is lower than 1
    

    This is because newtypes report their errors with an empty path, resulting in a lone : in the error message. This has now been fixed, and will report as:

    length is lower than 1
    

Full changelog

v0.17.0...v0.18.0