Looking for a new maintainer for std.uni/std.regex

[Dmitry Olshansky]

On Wednesday, 2 November 2022 at 15:32:56 UTC, H. S. Teoh wrote:
> On Thu, Nov 03, 2022 at 12:34:11AM +1300, rikki cattermole via 
> Digitalmars-d wrote:
>> On 03/11/2022 12:20 AM, Hipreme wrote:
>> > The greatest bug on std.regex is it being too slow to 
>> > compile, do you have any idea on what it could be right now? 
>> > Are you looking for fixes or an entire rework on it?
>> 
>> A feature that is known to have been useless is ctRegex, that 
>> needs to be deprecated.

I guess CTFEing big tables didn’t work since it’s been 10 years 
and we are exactly where it started - a proof of concept that is 
incredibly slow to compile with minor speed gains at run-time.

>> Perhaps that'll help things once removed?
>
> While ctRegex probably should be removed, I don't think that's 
> the problem.  Even when you don't use ctRegex, using regex() 
> alone slows down compile times by 2-3 seconds.  I think it may 
> be the excessive use of nested templates / CTFE deep inside 
> std.regex's internal implementation.

Regex is fairly simple in its use of templates - the whole thing 
is templated by Char which is hardly a big problem considering 
that Phobos is made of templates.

> I'm not sure if this can be fixed without rewriting from 
> scratch (which we don't want to do -- that would be too big of 
> an effort), but perhaps some careful profiling of the compiler 
> might help pinpoint the most egregious parts of the code that 
> could be improved.

I do not think one needs to go that deep, just look for immutable 
globals since that’s where the CTFE is which is synonym for slow.
>
> T