Re: PHP 6

No, but there are related issues that come up.

For example, once we remove the third string type (leaving only binary 
and unicode) we lose the ability to have automatic BC support for 
functions that have not been upgraded and still do RETURN_STRING(). 
Something like:

	dirname(__FILE__)."/myfile.php";

will issue a "cannot concatenate binary with unicode" error.

This does "break" PHP until we go through these functions and make them 
do the right thing. Can we live with it? Possibly, and it might even be 
good because it would light a fire under everyone's butt to upgrade the 
functions they are responsible for or cannot live without.

Another question is whether we still need the runtime_encoding setting 
and the corresponding converter. I initially thought that we can 
discard it, but there are many functions in PHP that use some 
underlying C function and in order to convert its result into Unicode 
they need to use some encoding. Whether we default to UTF-8, use 
default system encoding, or retain runtime_encoding setting needs to be 
discussed.

- Andrei

On Dec 12, 2005, at 12:10 AM, Derick Rethans wrote:

>> Have we finalized our Unicode decisions? I was talking to Dmitriy 
>> online and
>> we had some initial disagreement over which internal string types to 
>> keep,
>> IS_BINARY/IS_STRING or IS_STRING/IS_UNICODE. My point was that since 
>> Unicode
>> strings will be available both with unicode_semantics switch on and 
>> off, then
>> IS_UNICODE should remain invariant and it is IS_STRING that changes 
>> behavior
>> (however slightly).
>>
>> It would help a lot for all of us to get involved in this, at least 
>> partially.
>
> I thought we discussed this quite intensively at the meeting. And afaik
> we concluded on:
>
> http://www.php.net/~derick/meeting-notes.html#different-string-types
>
> Do you want to re-asses this now?