Improving std.regex(p)

[Ben Hanson]

== Quote from Don (nospam at nospam.com)'s article
> 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.
Good to know Don, thanks!