Closed future-highway closed 11 months ago
I don't think the trait HasLen
is used anywhere. I think I forgot to remove it in the rewrite.
So for the length validator, I would like to add an option to the validator for the type of length:
So you would call it like:
#[validate(length(min = 1)].
#[validate(length(min = 1, kind="chars")] // equal to previous line
#[validate(length(min = 1, kind="utf8_bytes")]
#[validate(length(min = 1, kind="utf16_bytes")]
What do people think? Not on this PR though, just to get some feedback while talking about it.
And I guess we can remove all the HasLen handling if it's unused
I don't have a strong opinion on the type of length since I'm not actually using this library anymore (I was wrapping the lib in my own validation library and HasLen
was my main use, so I never took full advantage of the features).
My only thought is that it may be an easy way to make a mistake by forgetting to specify. Maybe having distinct choices (e.g., length_in_u8
, length_in_chars
, etc.) would prevent such a mistake. count
could be used for Vec
and [T]
to distinguish them.
As I said though, I'm not using this library currently and it's probably a better idea to take the input of others.
I'll update the PR to delete HasLen
PR updated.
May also want to consider replacing the use of lazy_static
(see: https://github.com/rust-lang-nursery/lazy-static.rs/issues/214) with once_cell
which also has a lazy interface. I didn't think I should mix it in this PR.
Yes, lazy static will be replaced later, thanks!
This also implements #271 on next which is included in the code changes related to
HasLen
, though I don't see howHasLen
is used in this branch.Most of the code was eliminated by using generic implementations for
Option<T>
and&T
.