Skip to content
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

proposal: regexp/syntax: accept (?<name>...) in addition to (?P<name>...) #58458

Open
rsc opened this issue Feb 10, 2023 · 0 comments
Open

proposal: regexp/syntax: accept (?<name>...) in addition to (?P<name>...) #58458

rsc opened this issue Feb 10, 2023 · 0 comments
Labels
Milestone

Comments

@rsc
Copy link
Contributor

rsc commented Feb 10, 2023

Based on the discussion on rust-lang/regex#955, it seems that many regexp sources refer only to (?expr) for capturing group names, and at least a couple regexp implementations only support that form. Go, following RE2, only supports (?Pexpr). The original comment I wrote for RE2 says:

  // Check for named captures, first introduced in Python's regexp library.
  // As usual, there are three slightly different syntaxes:
  //
  //   (?P<name>expr)   the original, introduced by Python
  //   (?<name>expr)    the .NET alteration, adopted by Perl 5.10
  //   (?'name'expr)    another .NET alteration, adopted by Perl 5.10
  //
  // Perl 5.10 gave in and implemented the Python version too,
  // but they claim that the last two are the preferred forms.
  // PCRE and languages based on it (specifically, PHP and Ruby)
  // support all three as well.  EcmaScript 4 uses only the Python form.
  //
  // In both the open source world (via Code Search) and the
  // Google source tree, (?P<expr>name) is the dominant form,
  // so that's the one we implement.  One is enough.

Given the widespread usage and documentation, I am now inclined to accept (?expr) as well. There seems to be very little usage of (?'name'expr) so that one would still be rejected.

There would be no change to the data structures, only to the syntax accepted. (Go's regexp/syntax does not guarantee to round trip back to the exact same string.)

I talked to RE2 maintainer @junyer and he agreed to make the change in RE2 if Go does, which will help keep Go, RE2, and RE2/J in sync.

It also sounds like @BurntSushi is moving toward making the same change for Rust. It is not a goal for Rust and Go to exactly match, but it is more evidence for the decision.

@gopherbot gopherbot added this to the Proposal milestone Feb 10, 2023
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Feb 10, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Feb 10, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Feb 18, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 2, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 4, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 5, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 15, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 15, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 15, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 20, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Mar 21, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Apr 15, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Apr 17, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Apr 17, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Apr 17, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
BurntSushi pushed a commit to rust-lang/regex that referenced this issue Apr 17, 2023
It turns out that both '(?P<name>...)' and '(?<name>...)' are rather
common among regex engines. There are several that support just one or
the other. Until this commit, the regex crate only supported the former,
along with both RE2, RE2/J and Go's regexp package. There are also
several regex engines that only supported the latter, such as Onigmo,
Onuguruma, Java, Ruby, Boost, .NET and Javascript. To decrease friction,
and because there is somewhat little cost to doing so, we elect to
support both.

It looks like perhaps RE2 and Go's regexp package will go the same
route, but it isn't fully decided yet:
golang/go#58458

Closes #955, Closes #956
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Incoming
Development

No branches or pull requests

2 participants