Feature Request: Support for Early Exit on First Validation Failure

[onepiece-dz]

Description:

Hi, I'm using the go-playground/validator package and wanted to suggest a feature that could improve performance, especially when validating large structures with many fields.

Problem:
Currently, when we call validator.Validate.Struct, it performs validation on all fields, even if a field fails validation early. This can cause unnecessary overhead, especially when the structure has many fields. For example, if the first field fails validation, the subsequent fields are still validated, which can be wasteful in terms of both performance and processing time.

Feature Request:
I would like to request an enhancement that allows the validator to stop the validation process immediately when the first validation error occurs. This would provide the ability to exit early, which could significantly improve performance, especially in larger structures or cases where the first failure is the most critical.

Expected Behavior:
If a validation error occurs for any field, the validation process should terminate, and the first error should be returned.
No further fields should be validated once the first error is encountered.

Example Scenario:

type User struct {
    FirstName string `validate:"required"`
    LastName  string `validate:"required"`
    Email     string `validate:"required,email"`
}

user := &User{
    FirstName: "", // This will fail
    LastName:  "Doe",
    Email:     "[email protected]",
}

err := validate.Struct(user)
// On the first validation failure (FirstName), it should stop validation
// and return the error for "FirstName".

Why this is useful:
Performance: Early exit on the first failure would save time by avoiding unnecessary checks on the remaining fields.
Flexibility: It provides the ability to stop processing on the first failure, which is a common use case for many validation scenarios (e.g., form validation, input sanitation).
Compatibility: This feature could be an opt-in behavior, allowing users to opt into "early exit" validation, without breaking current workflows.
Possible Implementation:
This could be achieved by introducing a flag or option, such as WithEarlyExit or similar, that modifies the behavior of the Struct method. When set, it would ensure that the validation process stops after the first error.

[deankarn]

Hey @onepiece-dz I'm interested in learning more about your use case.

My interest lies mostly in one of your statements It provides the ability to stop processing on the first failure, which is a common use case for many validation scenarios (e.g., form validation, input sanitation)

One of the big reasons the library does all validation for all fields was because form validation & input sanitization was the main design driver.

Taking From Validation as the example when filling out a form returning all the fields' issues and reporting them to the user at once to correct before attempting to submit incurring another round trip network request vs returning only one, then having to submit and make another round trip network request and having to repeat that the number of incorrect fields.

Validation of fairly large structs are in the nanosecond to low microsecond ranges and the bulk of time for the form submission request dominated by network call and data transfer.

There may be use cases I'm not thinking of though where the external factors don't dominate the time and a few nanoseconds makes a difference and so would love to understand you use case better where this is so.

Thanks for any details you can provide.

[thenicolau]

Hi @deankarn

A scenario where I see this being very useful is in high-throughput processing pipelines or queues, where it would be better to return as soon as possible rather than continuing to validate a struct that is already incorrect, potentially saving some time in these cases.

Another scenario where I see this possibly being useful is in custom validations. In some cases I've worked on, we used external validations and API calls for fields. It wouldn't always be ideal to make unnecessary requests for a structure that we already know is invalid.