re/nre: mention nim-regex as the alternative

[Araq]

No description provided.

[juancarlospaco]

I agree; But this kinda leaves stdlib without Regex, thats a big missing feature compared to other programming languages...

Work to integrate regex into stdlib should be considered soon.

[dom96]

Agreed that we should incorporate this awesome library into stdlib.

There are multiple ways we can achieve this, depends on how the library's author wants the library to evolve (outside stdlib in its own repo or not). If in its own repo then the only way I can see this working is if we implement a feature in Nimble that allows packages to be included as part of Nim, and that then Nimble is aware that these packages are "installed".

[Araq]

If in its own repo then the only way I can see this working is if we implement a feature in Nimble that allows packages to be included as part of Nim, and that then Nimble is aware that these packages are "installed".

The "nim distro" idea. It's time to do it.

[konsumlamm]

Why not use one of the adminitions (like .. note:: or .. warning::)?

[timotheecour]

pros of pkg/regex: better API, pure nim
works at CT is potentially a moot advantage because of nitely/nim-regex#104 and because a vmops might work for re/nre (and maybe pkg/regex too)

performance wise, see this thread: nitely/nim-regex#57 tracking performance which was initially showing regex being 40x slower but @nitely has improved performance a lot since then, eg see nitely/nim-regex#58 (comment).

IMO we should still provide a comprehensive (and easy to re-run / update) benchmark on a variety of tasks before declaring pkg/regex as "the one true choice"

[nitely]

All I can say is nim-regex depends on unicodedb, and I think that makes it a no-go for including it into the stdlib.

@timotheecour performance concerns are valid, we need more benchmarks.

Why is re/nre outdated anyway? is this about the APIs, requiring pcre VS no dependencies, or what exactly?

[Araq]

For me it's about "requiring pcre VS no dependencies" plus the fact that both re/nre are hardly maintained.

[Varriount]

I agree; But this kinda leaves stdlib without Regex, thats a big missing feature compared to other programming languages...

Work to integrate regex into stdlib should be considered soon.

Or, we can just recommend people download the package, while carefully considering whether that implementation is suitable for inclusion into the standard library in the first place. Nim has already gone through 2 regex modules, let's try to avoid continuing the trend.

[ringabout]

Suggested change

	## NOTE: The `re` module is outdated, but going to be kept for backward
	## .. note:: The `re` module is outdated, but going to be kept for backward

ditto

[ringabout]

Suggested change

	## NOTE: The `nre` module is outdated, but going to be kept for backward
	## .. note:: The `nre` module is outdated, but going to be kept for backward

note or warning

[juancarlospaco]

Maybe a tiny new module on top of existing Regexes, multi-backend regex, kinda like:

initRe(backend = JsRe)   # backend = Nre , backend = X
let r: Regex = /[0-9]/i  # Generates newRegex("[0-9]", "i")

Then maybe users can "hook up" their own:

initRe(backend = CustomTypeOrConcept)  # Backend delegated to user.
let r: Regex = /[0-9]/i  # Features and Bugs here delegated to user.