We could maybe adopt nim-regex into the stdlib and deprecate both re and nre...
> Does this mean that the plan is to remove nre in the future?
If you feel out of the loop, the "real" plans that have some chance of being
done are tracked here:
I use this pure library in one of my projects
[https://github.com/nitely/nim-regex](https://github.com/nitely/nim-regex)
Does this mean that the plan is to remove nre in the future? That is, is it the
recommendation to use re for new projects? If such a change is being
considered, it would be nice to have a built in stand-alone regular expression
library. Its a bit annoying to have to distribute the pcre dll with
For performance, last I checked, re is faster than nre by a lot.
Thank you for the answers!
And after the v1 life, the worst that will happen is that you need to add `nre`
as a Nimble package dependency.
* for use in stdlib, IMO nre is the better design
* for use outside stdlib, IMO pkg/regex has a better design, eg works at CT,
and is pure nim code without pcre dependency; I'm curious about performance,
haven't seen benchmarks on this
Since both `re` and `nre` made it to version 1 of Nim, you can be certain that
they will be around for as long as there are interest in maintaining the 1.x
series :) That's the stability commitment of Nim v1.
Hello community! I want to clarify for myself and future programmers, what
standard regex library should we use now?
I found two discussions about future of both
[re](https://github.com/nim-lang/Nim/issues/2511) and
[nre](https://github.com/nim-lang/RFCs/issues/31) .
I'm a bit scared that nre
