Skip to content

Regex support #1239

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2 tasks done
Vyacheslav1557 opened this issue Mar 3, 2024 · 2 comments
Closed
2 tasks done

Regex support #1239

Vyacheslav1557 opened this issue Mar 3, 2024 · 2 comments

Comments

@Vyacheslav1557
Copy link

Vyacheslav1557 commented Mar 3, 2024

  • I have looked at the documentation here first?
  • I have looked at the examples provided that may showcase my question here?

Enhancement:

Why dont you add a new regexp tag like so

type Country struct {
	Name   string `validate:"required" regexp:"^.{1,100}$"`
	Alpha2 string `validate:"required" regexp:"^[a-zA-Z]{2}$"`
	Alpha3 string `validate:"required" regexp:"^[a-zA-Z]{3}$"`
	Region string `regexp:"^Europe$|^Africa$|^Americas$|^Oceania$|^Asia$"`
}

I know that it won’t be possible to add support for regexp inside the validate tag and maybe this is against the design, but regexp is also a basic tool that everyone needs.

@deefdragon
Copy link

One of the unfortunate things here is that this will only allow top level validation using regex.

One of the more useful regex use-cases that I can think of is validating a map's keys and or values to match a specific regex pattern.

That said, I personally disagree with the lack of regex validators in general and think there should at-least be some way to use regex. I suspect an un-reasonably large chunk of users of this library have added their own regex validator implementations (myself included).

@deankarn
Copy link
Contributor

deankarn commented Apr 4, 2024

Hey all, it seems like that this has come back around and more people are requesting regex support again and so feel the need to comment about why it doesn't exists in the base package and also why it likely continue to remain as-is.

  1. Many supported characters for regexes conflict with the parsing tag internals of this package, off the top of my head comma(,) and pipe(|) which already require special actions in validation params. With regexes only more case like this will crop up and outs handcuffs on what additions and changes can be added to this package without inadvertently making
    a breaking change.

  2. Having A regex tag hurts usage of other features down the line such as translations and reporting back more than just the validation failure to users. For example you could have have the message Validation failed for Name on the regex tag(not very useful in knowing why) or with registering a specific validation, backed by a regex still, Validation failed for Name on min_name_length tag as an example.

  3. Adding a regex tag would require adding some sort of mutex guarding and compiling which can cause a small amount of contention but also the possibility that a regex fails to compile at runtime when neither is strictly necessary to use regexes through registration of other tags.

  4. They hurt the readability of code, some can get very large (thousands of characters long).

  5. If you use the same regexes a bunch you end up copying it all over the place instead of registering a validation backed by a regex which can be reused and live, be maintained, optimized and corrected if an error/issue is found all in one place.

  6. If you really want a regex validation tag there's nothing stopping you from adding one pretty easily.

I might be missing more but have to start my day and think that's enough to demonstrate why it doesn't exist today and likely won't be added.

I know a lot of people would like it and reach for regexes regularly but I'm truly trying trying to help by not adding it because of the above reasons for both people and this packages sake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants