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

[Dmitry Olshansky]

On Wednesday, 2 November 2022 at 11:20:52 UTC, Hipreme wrote:
> On Wednesday, 24 August 2022 at 18:20:53 UTC, Dmitry Olshansky 
> wrote:
>> Time flies by and my work on D's std library has halted a long 
>> time ago mostly due to personal health issues.
>>
>> Since lots of people ask what they can do to help push D 
>> language forward I thought one great way is to take on the 
>> responsibility for std modules that have lost their 
>> maintainers.
>>
>> In particuar I willing to guide a volonteer into the low-level 
>> pits of std.regex and std.uni and hopefully let him or her 
>> continue the work I once envisioned for them or maybe choosing 
>> a different track of evolution altogether. Anyhow I'm willing 
>> to spend the time to transfer the knowledge so that at minimum 
>> there is someone more active than me to hold the line. 
>> std.regex is 2011's product with all of language bugs and 
>> quirks of that time, std.uni is 2012 and pretty much in the 
>> same position.
>>
>> Anyway reply to this message or mail me
>>
>> dmitry at olshansky dot me
>>
>> --
>> Dmitry Olshansky
>
> 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?

Basically this most likely has to do with static immutable tables 
initialized at compile-time and hence invoking heavy CTFE. Lazy 
initialization could be an option. Again someone have to look 
into it to be certain.

> Are you looking for fixes or an entire rework on it?

What would be the point in the entire rework? It took about 4 
months to write it from scratch, plus the bug fixes found after 
that. If anything I had a plan to support JITing regexes which 
should work faster than CTFE static regex codegen plus avoiding 
the compile-time penalty. Even that doesn’t require an entire 
rework, in fact it would nicely fit into what is there.