Validate generic struct inner values using existing tags even with private fields

[Fire-Dragon-DoL]

Hi,
I have a struct Maybe[T] that has a method IsUnset() bool and a method Elem() T.
The internal fields isSet and value are both private. I could make them public, but it would be dangerous.
As you might guess, if value contains something and IsSet returns true, Elem returns value. If IsSet is false, Elem shouldn't be used (otherwise panic happens).

Goal of this struct is to differentiate, when decoding JSON, if a field is unset, if a field is null, or if a field is set to something else (e. g. A string).

Example usage might be Maybe[*string], which means the string could be unset, could be set to null or set to a string. I'm writing a substitute for an HTTP API over which I have no control, so I must support this usecase.

I would like to be able to use existing tags to validate the inner value, so for example, I would like to do the following

struct Something {
  Foo Maybe[*string] `binding:custom_just,omitempty,gteq=1`
}

In my mind this would achieve the following: custom_just would use the other validations only if isset is true.
omitempty would skip string validation if value is null. Finally, gteq would apply to value of the struct, so check the length of the string.

Is it possible to achieve this? If yes, how?

I'm open to alternatives, I was considering decoding to a map.

Maybe struct is defined as:

type Maybe[T] struct {
  isSet bool
  value T
}

[deankarn]

@Fire-Dragon-DoL currently only custom validations, custom struct level validations or Registering a Custom type function to handle each individual type would be the only ways to handle that.

I am thinking about how to achieve this in a more generic way without the package needing to know each type beforehand to support my own similar Option generic struct.

I'm thinking about adding something similar to registering a custom type function but a custom interface function, the only issue is it's a very implicit thing to be doing which could cause unintended side-effects if anything else implements or changes to implement unknowingly the registered interface and so continuing to think about it more.

Until something like that can be added I think the best way is to use registering a custom type function, and example can be found in the examples here.

[Fire-Dragon-DoL]

Thank you so much for explaining this. That's more or less the conclusion I ended at, but I was hoping there was a different approach, since this basically forces me to use custom validations for each type, instead of being able to validate the data using the existing methods (essentially removing the tags usefulness)

[deankarn]

You will still be able to use the built in validations with the custom type function approach, it will allow you to unwrap the Maybe struct inner type or return nil if not set.

[Fire-Dragon-DoL]

Ok i misunderstood, I'll try this tomorrow and see where it goes

[deankarn]

@Fire-Dragon-DoL how did it work out?

[Fire-Dragon-DoL]

Didn't try yet, I had to pivot and will resume that project in two weeks. I will keep you posted!