Lester Caine wrote (on 21/10/2014):
If we are going down the root of keeping PHP7 as ascii only in the core, then ustring probably makes sense, but it does not address many of the areas where unicode is really needed.
Just a quick point: most of the core is not ASCII. PHP strings are byte strings, completely divorced from any encoding. A few native functions assume ISO8859-1 (or possibly Windows CP1252), but mostly they just juggle which ever bytes you give them.
The main exception I can think of is that numbers are often handled specially, with digits and separators as defined by ASCII. But since we're talking UTF-8, that doesn't need to change.
Handling unicode content outside the core is working reasonably at the moment, it is the problems such as using unicode keys for arrays which is the main area where unicoe is needed in PHP7 and so a more embedded handling is needed which may cut across yet another content wrapper?
I do think this is an important thing to consider, though. If this extension is genuinely just meant as a more modern and more performant way of doing things which mbstring and intl can already do, that needs to be clear in the way it's documented and publicised. If this gets publicised as "better Unicode support", users are naturally going to expect UString objects to start appearing in core, and in other extensions, and be disappointed that it's still just a toolbox for their own string handling.
-- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
