Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:77190
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.173 as permitted sender)
Message-ID: <5415CFC0.5020309@gmail.com>
Date: Sun, 14 Sep 2014 18:26:24 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CA+9eiLtnWLzN3hDPOUDWedNbnw=H4otkiz85NMUtZ0nz0O2+iw@mail.gmail.com> <54153A26.4080700@sugarcrm.com> <541549B1.7000602@lsces.co.uk>
In-Reply-To: <541549B1.7000602@lsces.co.uk>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Fix list() behavior inconsistency
From: rowan.collins@gmail.com (Rowan Collins)

On 14/09/2014 08:54, Lester Caine wrote:
> One has to assume first that what is returned is a simple byte
> string array while currently is IS possible that it will contain unicode
> characters?

Well, currently, every single string function in PHP treats a string as 
a simple byte array, apart from those in the mbstring and intl extensions.

What's more, there isn't really a single meaning of the term "Unicode 
character" - at its simplest, there are code points, but they're not 
necessarily the most useful unit; as I mentioned before [1], people 
often actually want to work with "grapheme clusters", what a writer of 
the language would consider "a single character".

If more integrated Unicode support is ever added, it will presumably be 
in the form of a new data type; if that type implements $foo[0] to mean 
"first grapheme cluster", then it would be natural for list($a,) = $foo 
to do the same. But there is no reason for that to stop list($a,) = $foo 
being equivalent to $foo[0] for existing strings, and mean "first byte".

[1] http://news.php.net/php.internals/72914

-- 
Rowan Collins
[IMSoP]