Add fail-fast for dicts

[uriyyo]

Change Summary

Add fail-fast feature to:

• dict
• typed-dict
• dataclass-arguments
• model-fields

Related issue number

#1345

Checklist

• Unit tests for the changes exist
• Documentation reflects the changes where applicable
• Pydantic tests pass with this pydantic-core (except for expected changes)
• My PR is ready to review, please add a comment including the phrase "please review" to assign reviewers

[uriyyo]

please review

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/validators/dict.rs	62.50%	2 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[codspeed-hq]

CodSpeed Performance Report

Merging #1543 will not alter performance

_{Comparing uriyyo:more-fail-fast (52b1266) with main (0cd11fe)}

Summary

✅ 163 untouched

[uriyyo]

After implementing this feature I thought maybe it's make sense to add kinda validation context structure to not duplicate fail-fast check logic, it can look like this:

struct ValidationContext {
    fail_fast: bool,
    errors: Vec<ValLineError>,
}

impl ValidationContext {
    fn new(fail_fast: bool) -> Self {
        Self {
            fail_fast,
            errors: Vec::new(),
        }
    }

    fn default() -> Self {
        return Self::new(false);
    }

    fn should_stop(self) -> bool {
        self.fail_fast && self.has_errors()
    }

    fn has_errors(self) -> bool {
        !self.errors.is_empty()
    }

    fn add_error(mut self, error: ValLineError) {
        self.errors.push(error);
    }
}

[davidhewitt]

Thanks, overall the implementation seems fine.

RE your refactoring idea, I was beginning to think of something similar recently, see #1517, probably this solves related problems.

I realise that looking at this, I'm a bit unsure what the user-facing result is. What order do they expect validation of fields to be in? Does it matter if we validate the first field but not the last N, because the second was fail fast? What if the next time we randomly did these in a different order, and the performance was different? Maybe there were even side effects 👀

Under what cases is fail-fast useful for a model?

I would love to understand some more about this. I think if it's about making errors shorter, we could make it easier to see just the first error. If it's about performance, well, maybe we just make validation faster so that fail-fast doesn't matter.

Unlike lists and sequences, with potentially large inputs, a model should have a relatively small finite number of fields, so I don't know how much performance is gained by failing early...

[uriyyo]

@davidhewitt Your points totally makes sense to me. I removed fail-fast for model and dataclass and left it for dict and typed-dict.

[davidhewitt]

Thanks, and sorry it took me long long to come back to this.

I fixed the merge conflicts, and removed the typed-dict feature for now. I think typed-dict behaves more like model and dataclass than other collections, so if we add it for those three types (which I think is not totally unthinkable but needs discussion) then we should add them all at the same time.