Re: What "Unicode support" really means

On 05/03/2014 07:38, Pierre Joye wrote:

**IMHO, how we answer these questions is more important to most users of the language than what the implementation looks like internally.**

This is what ICU and other libraries do and ensure. Each string operation, but byte sizes or codepoint APIs.

We need to make these decisions *for PHP* though - what, to a PHP programmer, should strlen($some_unicode_string) do? A good library will give us multiple options to choose from here.

My point is not to say that we should not design the userland part of Unicode support carefully but without a clean, functional and efficient internal implementation, everything else is irrelevant at this point.

I would tend to disagree: you can't decide on an internal representation, implementation, etc if you haven't decided what you are trying to achieve. For instance, if you want some common functions to work with grapheme clusters, then your internal implementation needs to have efficient processing of those. If we want to support locale-based collations, then locale should be baked into the design, not added as an afterthought. And so on. Even the selection of UTF-8 is as much about userland requirements as internal efficiency: converting to and from an external UTF-8 representation will be a common operation, so having an internal UTF-8 representation optimises for that. Regards, -- Rowan Collins [IMSoP]