Hi,
Le 15/02/2017 à 20:02, Andrey Andreev a écrit :
While that's an understandable argument, what happens if we flip it? Is
there any benefit to keeping it?
If it currently does nothing, and the only reason for keeping it is that it
may do something in the future ... Well, there will be side-effects to any
code that does use it today.
In other words, it's supposed to be providing forward compatibility, but
any attempt to actually utilize it may only result in a BC *break*.
It's not a function or class name, so nothing benefits from reserving it
either ... or am I missing something?
One of the many reasons why the Unicode PHP 6 project failed was that
this 'binary string' flag was introduced much too late to expect
developers to add it to their code in a realistic time frame. Even if
the subject is still bad memories for many of us, someone may want to
address it again in the future and, at this time, the 'binary string'
flag may become useful again. Actually, it might even be the only
positive thing to remain from this mess :). Combined with the fact that
it does not cause much confusion, I prefer keeping it.
The risk of future BC break for the code actually using it is minimal as
the meaning is clearly defined, and doesn't have to be redefined in the
future : such string must be considered as a collection of 8-bit
characters without any encoding/decoding, whatever the default way of
considering strings.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
