Improving std.regex(p)

[Don]

Ben Hanson wrote:
> == Quote from BCS (none at anon.com)'s article
>> Hello bearophile,
>>> Ben Hanson:
>>>
>>>> Can you output source code at compilation time and have D compile it,
>>>> or do you use a load of recursion like C++ TMP?
>>>>
>>> This can be done with string mixin. You can use compile-time
>>> evaluation to build a string of code, and the mix it in somewhere, the
>>> compiler will compile it. It's a dirty thing, but unless D3 gets
>>> macros, it's the thing to be used. You can use it to build a string of
>>> asm code too, because it's part of D syntax.
>> OTOH, and IHMO it should be avoided where you can, kinda like goto. 
(For
>> one things, forget having usable line numbers in your error messages.) 

Whenever that happens, it's a compiler bug.
If you can produce a test case where that happens, please put it in 
Bugzilla.

You
>> can often get a lot done with static if, tuple foreach, const values feed
>> to boilerplate code and the like with just a scattering of one or two line
>> mixins stuffed in the middle.
>>> Bye,it.
>>> bearophile
> 
> It occurred to me that you could have a normal regex library that builds the regex at
> runtime, debug it, produce a code generator (similar code to re2c), debug that and then just
> wrap it with the mixin at the end. If you run into bugs, you can just do it at runtime
> instead and debug. The nice thing is, if I can get this converted, the lexer library is just
> slightly different. That means you could have the same approach with a lexer generator! This
> would lead to huge interest from the boost.spirit guys...

That is exactly the way I recommend to develop CTFE code. Get the code 
completely working, run unit tests on every component, and then CTFE it.