Would there be interest in a SERIOUS compile-time regex parser?

[Walter Bright]

Don Clugston wrote:
> The question is -- would this be worthwhile? I'm really not interested 
> in making another toy.
> It's straightforward, but tedious, and would double the length of 
> std.regexp.
> Would the use of templates be such a turn-off that people wouldn't use it?
> Do the benefits exceed the cost?

Yes, for the following reasons:

1) I think it would make for faster regexp's, more than just by omitting 
the compile step. That's because the bytecoded program wouldn't need to 
be interpreted.

2) When I show the current one to people, as opposed to Eric Niebler's 
C++ one, the response is "but the D one is just a toy" with the 
implication that D is just a toy.

3) I wrote std.regexp long before people needed or asked for it. I knew 
it would eventually become a critically needed module, and that came to 
pass. It was nice that it was there when they needed it, and the time 
passed had ensured that it was a solid piece of code.

4) Your crafting of the current toy version was the catalyst for a big 
leap forward in D's templating system. Doing a professional one may 
expose critical problems that need to be fixed, and even if no such 
flaws are discovered, it would prove that D's TMP capabilities are up to 
scratch.

Sure, a lot of people are turned off by templates. That's one of my 
motivations for making things like associative arrays usable without 
templates. But for the people who do use templates, this can be a very 
big deal.

I think it should be in a separate module, say, regexp_static or 
something like that. Ideally, the user can switch between the two just 
by changing the module name in his code, and compare.