Re: [Discussion] Should All String Functions Become Multi-Byte Safe?

> On Aug 16, 2024, at 3:36 PM, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> wrote: > On 16 August 2024 19:44:22 BST, Mike Schinkel <mike@newclarity.net> wrote: >> Let me see if I understand your argument correctly? You are asserting that Unicode is >> "too complex" to be handled in the standard library so that complexity should instead be >> shouldered individually by each and every PHP developer who needs to work with Unicode text in PHP, >> which is many PHP developers if not eventually most. Is that your argument? > > > Not really, no. I'm definitely in favour of including more Unicode-based string handling > functionality, by improving and extending ext/intl, or coming up with new convenience wrappers for > common tasks. Your prior reply came across to me as a closed-end slamming-the-door on the topic because of "what we can't do," which is why I commented on. This most recent reply OTOH was an example of exploring "what we can do" to improve PHP. So kudos for this reply; big plus. > What I'm always sceptical of is the idea that you could ever consider such functionality > "complete", or that "Unicode support" can ever be a single deliverable, rather > than an ongoing aspiration. (And consequently, I'm sceptical of any language which says it has > achieved that.) To be clear I don't think anything can ever be considered "complete" unless you are talking something as limited in scope as numeric addition. And even then, supporting imaginary numbers might arise. So while it is not a problem to be explicit about it even if redundant, having it be an underlying reason to argue against useful functionality — if it is ever used in that way — seems counter-productive. Nothing precludes a follow-up RFC after an initially successful RFC is implemented and shipped. > I also think "Unicode support" is probably the wrong angle to approach from; it leads > to features like IntlChar, which technically provides access to tons of data from the Unicode > standard, but practically has no use for 99% of PHP developers. Instead we should be talking about > "internationalisation support", of which handling different writing systems is one (fairly > big) part. I am not sure I agree with you that adding Unicode support is the wrong angle, per se. A strong argument could be made that Unicode support is a necessary but not sufficient building block for "internationalization support." IOW, if you want to get to the latter it is probably a lot easier to start with the former as the scope of the latter is by-nature larger. After all, perfect is the enemy of the good and waiting for a full-press effort for internationalization support could well push off Unicode support long down the road. Still, *if* "full" internationalization support can be achieved in the shorter term it would be bikeshedding for me to argue against it. -Mike