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
By default, the string parsing for regular expressions is doing case insensitive checks by lowercasing the regex. Is there a reason for this? I am considering making changes to allow regex comparison to me made based on what you supply. EG: ^A\d{1,}.\d{1,}.1.\d{1,}$
If required I will create a pull request but before I do I want to ensure you are happy with the approach.
I could create a new property similar to _regex but call it _regexraw and then process accordingly.
I could just modify to not lowercase the string at all and let a user apply the /i to the end if they want it to be case insensitive.
Something else.
Personally, I think approach 2 (whilst breaking current functionality) is the most logical way forward.
Thoughts?
The text was updated successfully, but these errors were encountered:
Huh, I am surprised this is happening. The tests actually tests for successful matches of upper-case against an upper-case input, and lower-case with ignore-case against upper-case input, but never tests for failure of lower-case against an upper-case input without ignore-case.
Would be happy to take a PR on this, option 2 makes the most sense to me as well.
Hi,
By default, the string parsing for regular expressions is doing case insensitive checks by lowercasing the regex. Is there a reason for this? I am considering making changes to allow regex comparison to me made based on what you supply. EG: ^A\d{1,}.\d{1,}.1.\d{1,}$
If required I will create a pull request but before I do I want to ensure you are happy with the approach.
Personally, I think approach 2 (whilst breaking current functionality) is the most logical way forward.
Thoughts?
The text was updated successfully, but these errors were encountered: