Hi,

I tried using named submatch for ctRegex... it works but seemingly only for maximum 1 named submatch...

OK (\w changed to \S to avoid, out of memory)
`(?P<var>\S+)\s*=\s*(\d+);`
`(?\S+)\s*=\s*(?P<value>\d+);`

NOT OK
`(?P<var>\w+)\s*=\s*(?P<value>\d+);`

Is this a known bug? I used the regex example from the Library Reference, converting it to ctRegex...

Lookup named submatch.
import std.regex;
import std.range;

auto m = match("a = 42;", regex(`(?P<var>\w+)\s*=\s*(?P<value>\d+);`));
auto c = m.captures;
assert(c["var"] == "a");
assert(c["value"] == "42");
popFrontN(c, 2);
//named groups are unaffected by range primitives
assert(c["var"] =="a");
assert(c.front == "42");

On 08-Aug-12 00:24, Daniel wrote:
> Hi,
>
> I tried using named submatch for ctRegex... it works but seemingly only
> for maximum 1 named submatch...
>
Great! I never tried ;) Should just work though...

> OK (\w changed to \S to avoid, out of memory)
> `(?P<var>\S+)\s*=\s*(\d+);`
> `(?\S+)\s*=\s*(?P<value>\d+);`
>
> NOT OK
> `(?P<var>\w+)\s*=\s*(?P<value>\d+);`
>
Would be great to know what exactly is not OK :) Error message etc.


> Is this a known bug? I used the regex example from the Library
> Reference, converting it to ctRegex...

I know it's hitting assert failure during parse. It's a CTFE bug, there are some other limitations but they are not in bugzilla yet.

That all being said experimental tag on ctRegex in DDoc is here for a reason, and that is: ctRegex can't compile nor match full regex testsuite.
(out of memory + bugs)
>
> Lookup named submatch.
> import std.regex;
> import std.range;
>
> auto m = match("a = 42;", regex(`(?P<var>\w+)\s*=\s*(?P<value>\d+);`));
> auto c = m.captures;
> assert(c["var"] == "a");
> assert(c["value"] == "42");
> popFrontN(c, 2);
> //named groups are unaffected by range primitives
> assert(c["var"] =="a");
> assert(c.front == "42");
>


-- 
Dmitry Olshansky

On Tuesday, 7 August 2012 at 20:51:28 UTC, Dmitry Olshansky wrote:
>
> Great! I never tried ;) Should just work though...
hehe :)

>
> That all being said experimental tag on ctRegex in DDoc is here for a reason, and that is: ctRegex can't compile nor match full regex testsuite.

Understood, thanks for your quick response nevertheless. :)

There are different errors depending on which of the two captures is attempted to be accessed.

auto m = match("a = 42;", ctRegex!(`(?P<var>\S+)\s*=\s*(?P<value>\d+);`));
auto c = m.captures;

// c["var"]; =>
core.exception.RangeError@std.regex(2145): Range violation

// c["value"]; =>
Object.Exception@C:\D\dmd2\windows\bin\..\..\src\phobos\std\regex.d(2145): no su
bmatch named value

On 08-Aug-12 02:05, Daniel wrote:
> On Tuesday, 7 August 2012 at 20:51:28 UTC, Dmitry Olshansky wrote:
>> That all being said experimental tag on ctRegex in DDoc is here for a
>> reason, and that is: ctRegex can't compile nor match full regex
>> testsuite.
>
> Understood, thanks for your quick response nevertheless. :)
>
> There are different errors depending on which of the two captures is
> attempted to be accessed.
>
> auto m = match("a = 42;", ctRegex!(`(?P<var>\S+)\s*=\s*(?P<value>\d+);`));
> auto c = m.captures;
>
> // c["var"]; =>
> core.exception.RangeError@std.regex(2145): Range violation
>
> // c["value"]; =>
> Object.Exception@C:\D\dmd2\windows\bin\..\..\src\phobos\std\regex.d(2145):
> no su
> bmatch named value
>
Yikes! Something is wrong with hash-table that maps names to indexes (it's just it).

File this as bug please, including the example.

-- 
Dmitry Olshansky