On Thu, Dec 15, 2022 at 4:56 PM Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 15.12.2022 at 16:34, Derick Rethans wrote: > > > I have just published an initial draft of the "Unicode Text Processing" > > RFC, a proposal to have performant unicode text processing always > > available to PHP users, by introducing a new "Text" class. > > > > You can find it at: > > https://wiki.php.net/rfc/unicode_text_processing > > > > I'm looking forwards to hearing your opinions, additions, and > > suggestions — the RFC specifically asks for these in places. > > | As the implementation requires ICU, this would also mean that PHP will > | depend on the ICU library. > > Our current stance is that a minimal PHP should be buildable without > requiring any "non-standard" libraries; this is the reason why we bundle > PCRE. If we wanted to stick with that policy, we would need to bundle > ICU, what might not be the best idea – it's generally not great to have > bundled libraries which are still maintained outside of php-src, and > especially for such huge libraries. > > I agree with this. Bundling ICU doesn't seem like a good idea. Wouldn't be better to base on something smaller that can be bundled and does the job? For example NJS and QuickJS use their own implementations which seem to be fine. Especially https://github.com/bellard/quickjs/blob/master/libunicode.c seems like something that we could fork and maintain potentially. Cheers Jakub
