From a user perspective, this is extremely valuable. What an amazing improvement; unbounded especially. I do hope this would make it into actual RE2 & go.

When I use regex, I expect to be able to lookbehind, so I am routinely hit by RE2's limitations in places where it's used. Sometimes the software uses the entire matched string and you can't use non-capturing groups to work around it.

I understand go's reasons, ReDoS etc, but the "purism" of RE2 does fly in the face of practicality to an irksome degree. This is not uncommon for go.

▲

masklinn 16 hours ago | parent | next [-]

The authors’ previous article (linked in this one) was about doing this in re2 (https://systemf.epfl.ch/blog/re2-lookbehinds/), and they have a fork with those changes though I don’t know that they have a PR.

> the "purism" of RE2 does fly in the face of practicality to an irksome degree

It’s not purism tho. There are very practical reasons to want an FA-based engine, and if you compromise that to get additional features then the engine is pointless, you could have just used a backtracking engine in the first place.

▲

ncruces 13 hours ago | parent [-]

I couldn't find the link in that page, but the fork is here, and seems to be up-to-date: https://github.com/GerHobbelt/re2

If you need that from Go, you can probably use that to create a fork of this: https://github.com/wasilibs/go-re2

	▲	aurele_ 3 hours ago \| parent [-]
		The RE2 fork from the blog post above is this one: https://github.com/epfl-systemf/re2-lookbehinds

▲

hnlmorg 17 hours ago | parent | prev | next [-]

The point of standard libraries is to provide sane default behaviours. Go’s regexp package is a sensible default.

For instances where you need something more sophisticated than what’s in the standard library, you reach for 3rd party modules. And there are regex libraries for Go which support backtracking et al.

There’s definitely some irksome defaults in Go, but the choose of regex engine in the regexp library isn’t one of them

▲

arp242 9 hours ago | parent | prev | next [-]

> I understand go's reasons, ReDoS etc, but the "purism" of RE2 does fly in the face of practicality to an irksome degree.

Preventing ReDos is literally the reason RE2 exists though, so I don't think it's "purism" to not implement these things. What you want is not unreasonable, but fundamentally incompatible with the goals of RE2.

Ways to do look-behinds in linear time, as detailed in this article, are a relatively new development AFAIK(?) I don't think the RE2 people are principally opposed to integrating that if it can be done well. I suspect someone will have to write a patch though, since the main RE2 maintainer died last year.

▲

progbits 15 hours ago | parent | prev | next [-]

While I agree this is a common golang theme, in this case I believe this decision predates the golang implementation and comes from the C++ RE2 days, no?

▲

chubot 16 hours ago | parent | prev [-]

What are some examples of problems where you’ve used lookbehinds?