Any plans to use code generation (possibly with generics) to avoid reflect at runtime?

[ghostsquad]

Any plans to use code generation (possibly with generics) to avoid reflect at runtime? This is likely plenty fast, but I think it could be even faster without the use of reflect? Now that go 1.18 is out, I imagine that generics, and some light code generation could likely go a long way.

[deankarn]

I think that these are two separate questions in one.

To address the use of generics: I'm not sure generics can be leveraged in the way you might be thinking. Types need to be known ad compile time, which is I think where your light code generation comment comes in.

As for the code generation, I've thought about this for a very long time, but haven't had the time to implement my idea. If I was going to do any code generation I'd create a new repo and go totally code generated validations, no generics needed based off of the validation tags. One day I'll get to looking into this, I was kind of waiting for generics to be in the mix as it could drastically change the code generation logic when generating the validations.

[alexgarzao]

The code generation approach seems like a very good approach.

Has anyone looked into this?

Could this be a valid approach for validator design?

[XavierFilipe]

I agree with the code generation, that makes sense.

@deankarn Would it really need to be in a different repository?