Feature request: CoerceToNonGeneric for TOut types

System Details

• FluentValidation version: 8.4.2

Issue Description

I’m writing some (generic) custom validators, and I was inspired by the way you wrote the LengthValidator. However, I was wondering, why you have multiple CoerceToNonGeneric extensions but not just one like the one below:

public static Func<object, TOut> CoerceToNonGeneric<TIn, TOut>(this Func<TIn, TOut> func)
{
    return x => func((TIn)x);
}

Less code, and supports all flavors you could wish for out of the box. Or am I missing something?

(I can create a pull request if you like)

[JeremySkinner]

Guidelines for extending FV are covered here: https://fluentvalidation.net/custom-validators this shows the several different ways you can implement custom validation. Is there anything else you think that should cover?

[JeremySkinner]

Is reusing the same instance tricky here?

You definitely shouldn’t do that. A validator stores all of its configuration, so for example if you call WithMessage on this validator, it will affect the NoIPBasedEmailAddressValidator across all validator, which you definitely don’t want (and also isn’t thread-safe). You should instantiate it each time.

I think generic documentation on when to implement a custom validator, and when to just extend on existing ones in an extension method make more sense would help developers a lot.

I think this is already pretty clear in the docs. Under the section on property validator classes section it says “This is an advanced technique that is usually unnecessary.” Basically: property validator classes are how FluentValidation itself is implemented. Typically using this lower-level API would be unnecessary for consumers, and breaks you out of the “fluent” world, but the option is there. I don’t feel that offering advice on when to use one approach over the other is necessarily something I want to do - I present both options in the docs and it’s really up to you as the developer to decide which approach you prefer.

My mistake. I meant Properties only. And of course (if you use expressions on fields, they work to, I noticed), but in your naming you went for “Property”, not for “Member”.

Member is a more generic term that covers both fields and properties. You can of course use FluentValidation against both (as well as even method calls if you really want to, but that’s not a great idea as it bypasses all caching), but in the .NET world generally fields are not exposed publicly, but are encapsulated behind properties. Because FluentValidation is designed to validate the public surface of an object, it makes more sense to refer to properties (as this is the intended use case) as this is what users are more likely to be exposing publicly.

Hope that makes sense