On 21.02.2022 at 16:52, Craig Francis wrote: > On Mon, 21 Feb 2022 at 09:09, Rowan Tommins <rowan.coll...@gmail.com> wrote: > >> Making the extension always available (impossible to compile without it) >> is a potential option, and I think has been suggested before; I'm not >> sure of the exact pros and cons. >> > > [...] > > I would personally encourage everyone to have ext/intl installed and use >> grapheme_strlen() instead of mb_strlen(), because knowing whether a >> particular instance of the string "Nguyễn" is written with 6, 7, or 8 >> code points is not nearly as useful as knowing that it looks like 6 >> "characters" to a user either way. > > Good point. > > I would like something that can be relied on to convert a strings character > encoding... I assume it's a question of ext/mbstring having all of its > dependencies already present (easier to compile?), vs ext/intl potentially > being more useful (if a little bigger?).
We cannot make any extension with external dependencies mandatory. If we would require ext/intl, we had to bundle ICU, which is highly unlikely to happen. Making ext/mbstring (without ext/mbregex) mandatory would be an option, but there should be a separate RFC about that. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
