You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's easy to think that required means that a field must be provided. We have plenty of examples where required is used on a string value, even though it's a no-op when used on string values.
required is also non-orthogonal to nonzero, which does a similar job.
We could just use nonzero everywhere, but nonzero is itself somewhat confusing, because when used on a pointer to a numeric type, it's not entirely clear whether it is referring to the pointer or the numeric value.
As a future breaking change, we could perhaps remove nonzero entirely and make required be exactly the same as the current nonzero validation. This would bring the tags more into line with the conventions used by another validator package.
// TODO this functionality is arguably confusingly non-orthogonal
// to that of nonzero. The behavior of nonzero is also arguably
// confusing for pointers to numeric types, so as a future breaking
// change, we could change required to be essentially the same
// as nonzero and remove nonzero.
The text was updated successfully, but these errors were encountered:
It's easy to think that
required
means that a field must be provided. We have plenty of examples whererequired
is used on a string value, even though it's a no-op when used on string values.required
is also non-orthogonal tononzero
, which does a similar job.We could just use
nonzero
everywhere, butnonzero
is itself somewhat confusing, because when used on a pointer to a numeric type, it's not entirely clear whether it is referring to the pointer or the numeric value.As a future breaking change, we could perhaps remove
nonzero
entirely and makerequired
be exactly the same as the currentnonzero
validation. This would bring the tags more into line with the conventions used by another validator package.// TODO this functionality is arguably confusingly non-orthogonal
// to that of nonzero. The behavior of nonzero is also arguably
// confusing for pointers to numeric types, so as a future breaking
// change, we could change required to be essentially the same
// as nonzero and remove nonzero.
The text was updated successfully, but these errors were encountered: