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.



PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to