Validate each field individually

[Zizico2]

Is it possible (would it be possible?) to have each field validated when it is added?

It could look something like Foo::builder().x(1).try_into().y(2).try_into().z(3).try_into().build();.

[idanarye]

What does try_into have to do with anything? Shouldn't individual field validation mean that a setter returns a Result?

Either way, unlike #67 this is not something we can solve with a trait impl because we'd need one for each field. Maybe when const macros would support &str...

[Zizico2]

Yeah, idk why I thought of try_into.

This would make most sense I guess? Foo::builder().x(1)?.y(2)?.z(3)?.build();.

Idk much about how typed_builder works. Do you think I couldn't find a way to make this work, that you would accept?

[idanarye]

It can be done, but we need to come up with a good syntax.

[l-7-l]

Maybe you could use newtype instead

[evbo]

can we provide our own build implementation?

Then we could run all validation before/after calling build like you do in derive-build.

[idanarye]

So... something like this?

#[derive(TypedBuilder)]]
#[builder(build_method(validate))]
pub struct Foo {
    x: i32,
    y: i32,
}

impl ValidateBuild for Foo {
    type Error = FooError;

    fn validate_build(&self) -> Result<(), Self::Error> {
        if self.x < self.y {
            return Err(FooError::XIsSmallerThanY);
        }
        Ok(())
    }
}

Which will make build() do the build, run validate_build, and return a Result<Foo, <Foo as ValidateBuild>::Error>?

Then again, #95 can already do that and more. I haven't looked at it yet because it's a draft.

[evbo]

@idanarye wow, you're very active on this repo, thank you!

Yes I think so. Here's a working version. The only imperfection is... well.. that higher-kinded eyesore!

trait ValidBuild<T> {
    type E;
    fn build(self) -> Result<T, Self::E>;
}

// the only wrinkle: higher-kinded type gets arbitrarily long depending on number of non-default fields/their type...
impl ValidBuild<Example> for ExampleBuilder<((), (String,), (), (String,), (), (String,), (), (String,), (), (), ())> {
    type E = String;
    fn build(self) -> Result<Example, Self::E> {

        // notice I'm using a private builder, per: https://github.com/idanarye/rust-typed-builder/blob/97edb3fa740f60cf519f690e07fb2a4afa17d54f/examples/complicate_build.rs#L6
        let g = self.__build();

        // DO VALIDATION ON IT
        
        Ok(g)
    }
}

Notice there's 2 benefits:

• I can customize validation
• Downstream logic could enforce only Validated types are used, e.g.:

fn process_only_valid<T: ValidBuild + DoSomething>(v: T) {
    println!("thanks for the valid data!! processing it now...")
    v.do_something()
}

[idanarye]

wow, you're very active on this repo

Uh... not really. TBH I don't even use this crate myself anymore.

The only imperfection is... well.. that higher-kinded eyesore!

As bad as ((), (String,), (), (String,), (), (String,), (), (String,), (), (), ()) looks, your example still doesn't show the true horrors of working that way. It only handles a specific state of the builder, where the second, fourth, sixth and eighth values are set while the first, third, fifth, seventh, ninth, tenth and eleventh fields are not set. Assuming all fields are optional, you'd have to write $2^{11} = 2048$ such impls. Or... use generics, which can get a bit cumbersome:

impl<
        F1: Optional<String>,
        F2: Optional<String>,
        F3: Optional<String>,
        F4: Optional<String>,
        F5: Optional<String>,
        F6: Optional<String>,
        F7: Optional<String>,
        F8: Optional<String>,
        F9: Optional<String>,
        F10: Optional<String>,
        F11: Optional<String>,
    > ValidBuild<Example> for ExampleBuilder<(F1, F2, F3, F4, F5, F6, F7, F8, F9, F10, F11)>
{
    // ...
}

Also, when you need to actually check the values - you'll be forced to do it positionally. The Optional trait can help you get abstract away whether or not the value is set (maybe we can add a method to it for validation), so there is at least that, but working with this would still be a pain.

Building the actual struct before validating it is so much easier.

[evbo]

Building the actual struct before validating it is so much easier.

100% agree but I want to enforce validation and so prevent struct from being built without validation being run on it.

Fortunately we're not refactoring the positions of fields much and I'm thinking this is just a band-aid until that PR (#95) gets merged, which looks way better than what I have worked out. We also don't build with different arguments, ever (except in unit tests that use Default for field types not yet present in the struct shown above).

Just curious, if not this crate which do you prefer for this sort of use-case? To me this repo is the "Goldie Locks" as I've tried derive-build, derive-new, validator... None of them can do all 3:

1. check required fields set at compile-time
2. guarantee validation is run (no way to build the struct without validation)
3. auto-generate impl needed to init/validate the struct without dramatically increasing compile-time

[idanarye]

100% agree but I want to enforce validation and so prevent struct from being built without validation being run on it.

I get that desire to validate the data fields before building the struct, but I don't think it's worth the volatile and cumbersome it'll require. Building an invalid struct is not that bad when it can't escape module functions. It's a shame that fields defaults will be invoked (possibly with side effects) and that the destructor will be called, but that still not bad enough to justify the syntax required for pre-build validation.

Just curious, if not this crate which do you prefer for this sort of use-case?

The reason I don't use this crate myself is not that I found something better - it's just that I don't find the pattern as useful as I originally thought it'd be. With Rust Analyzer it's so easy to just auto-fill the struct fields and/or to generate construction methods, that I can easily go without generating builders for my structs.

If you are looking for alternatives though, you should check out Bon.

[evbo]

I see where you're coming from. For my it's different because I write code that a dozen or more developers might extend, completely break, and then blame the galaxy for not telling them better how to write their code.

So when I can, I prefer to use as many static guardrails as possible - beyond what I would need.

But then there's another side to this: trusting external APIs and vendors. If my microservice is consuming data from another team's API that I know they aren't testing or even QAing, then it pays handsome dividends using these runtime checks.

So to me it's all about defensive programming and you have the blue ribbon in my opinion! Are you planning on merging in #95 anytime soon?