Closed timotheecour closed 4 years ago
That's re
and nre
behaviour. The workaround is to use match(txt, re"abc", m, start=1)
, or to add openArray[char]
support so you can pass toOpenArray(src, 1, src.len-1)
and start=0
.
That's re and nre behaviour then it seems like a bug that we should report in nim repo
match(txt, re"abc", m, start=1)
wouldn't work if my regex is "^abc"
instead of "^abc$"
though IIUC
as a workaround, how about adding a simple bool flag, treatStartAsStart ?
then it seems like a bug that we should report in nim repo
Thank you. I think it's a bug too, but I was trying to convince myself it's a feature :P.
match(txt, re"abc", m, start=1) wouldn't work if my regex is "^abc" instead of "^abc$" though IIUC
Yeah. That's why I suggested toOpenArray.
Since no other regex library has re/nre behaviour, and no one has reported the previous behaviour to be wrong, I'll label this as a bug and fix it.
thanks for the fix! I've submitted https://github.com/nim-lang/Nim/issues/14284
@nitely so in light of https://github.com/nim-lang/Nim/issues/14284 should we re-open to match re/nre behavior? sorry I was wrong initially on this one, the start
+ preserving context
argument (eg https://github.com/nim-lang/Nim/issues/14284#issuecomment-626562406 or https://github.com/nim-lang/Nim/issues/14284#issuecomment-626673562) is convincing
Yes, I'll revert the changes.
/cc @nitely I was having a weird error in some program until I traced it back to a regression in nim-regex:
ff6ab82: works master (92ff73c0c3a63d70a7b870dd17e5cd0c23b77282) : fails
git bisect says it's 92ff73c0c3a63d70a7b870dd17e5cd0c23b77282