-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[API Proposal]: Add System.Text.RegularExpressions.ValueMatch.GroupName
#110383
Comments
I don't understand the proposed semantics here. The match being reported is for the whole expression, not a part of it. Seems like what you're really after is all of the capture group information. That's covered by #73223. |
In #73223 how would you know which group is matched?
e.g. when there's multiple groups like the example mentioned: The current |
It does, both positionally: |
That's exactly what I mean. You can lookup groups by name and index if they are defined in a sequence like the example in the docs, but when each match comes from disjuctive groups, it would help if you know the matched group name/index in advance, otherwise you will need to call GetGroupValueSpan for each name and skip if its unmached. |
And when multiple groups capture, this property doesn't make sense. |
I might be looking at it in a wrong way, what I'm trying to do is to make a |
Today with Match/Matches, that's just a simple check per group: using System.Text.RegularExpressions;
Match m = Regex.Match("abc", @"(?<n>\d+)|(?<w>\w+)");
if (m.Success)
{
if (m.Groups["n"].Success)
Console.WriteLine("matched n");
if (m.Groups["w"].Success)
Console.WriteLine("matched w");
} #73223 is about coming up with a good way to represent this in a safe manner for the non-allocating EnumerateMatches. If a |
Would you imagine an API like this could be implemented more efficiently? namespace System.Text.RegularExpressions;
public readonly ref struct ValueMatch
{
// only returns successful matches
+ public ValueGroupEnumerator EnumerateGroups();
} A hypothetical |
The API originally proposed in #73223 is not one we'd ship. That issue is just tracking the general desire to ship an allocation-free way of enumerating matches with full detail about captures. One possible way of doing so would be an enumerator like you allude to, though usability would be an issue with that design; there are lots of uses where folks pull out multiple named capture groups from a match, and having to enumerate to find them would be less than ideal. I suggest switching over to that issue to contribute to its design. |
Closing as a duplicate of #73223. Thanks. |
Background and motivation
Currently
EnumerateMatches
returns the match bounds but it doesn't expose any info about the capture group that the match comes from.API Proposal
API Usage
Alternative Designs
No response
Risks
No response
The text was updated successfully, but these errors were encountered: