[rsstack]

I used this concept once to write the validation logic for an "IP RegEx filter" setting. The goal was to let users configure an IP filter using RegEx (no, marketing people don't get CIDRs, and they knew RegEx's from Google Analytics). How could I define a valid RegEx for this? The intersection with the RegEx of "all IPv4 addresses" is not empty, and not equal to the RegEx of "all IPv4 addresses". Prevented many complaints about the filter not doing anything, but of course didn't prevent wrong filters from being entered.

[Etheryte]

Wouldn't a simpler solution work here? Instead of trying to validate the filter regex, show some sample IP addresses or let the user insert a set of addresses, and then show which ones the filter matches and which ones it doesn't. Also helps address the problem of incorrect filters.

[rsstack]

The odds of the sample addresses matching is essentially zero, and adding work to the user is counterproductive.

[Etheryte]

I'm not sure I agree — most common regex editing tools available online include a section for adding test strings to verify what you actually wrote is correct. Clearly there is a benefit to it. In similar vein, allowing the user to test before they commit and then test actually reduces their work load, they don't have to drop and then reload the whole regex in their mind.

[rsstack]

Sure, I use that when authoring and editing a RegEx. That's not the same as entry validation.