Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96745
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender)
To: =?UTF-8?Q?Pedro_Magalh=c3=a3es?= <mail@pmmaga.net>,
 PHP Internals List <internals@lists.php.net>
References: <cdd4edeaf066e73ca2ebdede5d5c535b@pmmaga.net>
Message-ID: <52157a07-edf4-5c43-4abc-4cf2f3d869ee@php.net>
Date: Sun, 6 Nov 2016 20:56:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <cdd4edeaf066e73ca2ebdede5d5c535b@pmmaga.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Binary string forward compatibility removal
From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=)

Hi,

it was stated during the pre-7 discussions, that this flag would be kept 
for possible future unicode-compliant developments. So, people needing 
binary strings are still encouraged to use the flag, even if it is not 
used in the current versions.

Regards

François

Le 06/11/2016 à 20:22, Pedro Magalhães a écrit :
> Hi internals,
>
> I've created a PR (https://github.com/php/php-src/pull/2187) aiming at
> the removal of the binary string forward compatibility.
>
> Reproducing the description of the PR:
> ----
> In version 5.2.1, the b prefix and the (binary) cast were introduced for
> forward compatibility with the PHP6 project. As it is known, that
> project never came to be. However, these are still accepted by the
> language scanner although ignored from then on.
>
> This PR aims at removing those as they are naturally confusing given
> that they are simply ignored or, in the case of the cast, the same as
> casting to string.
>
> However, I've separated this PR in 2 commits because the removal of the
> (binary) cast will bring a more serious BC break issue: On the PHAR
> extension, the current default stub for PHAR's makes use of the binary
> cast. I've removed it from the default stub and fixed the tests that
> made use of it but this means that the old PHARs that make use of this
> default stub will be broken.
>
> What seemed to be a simple task actually turned out to be far more
> complex given the number of tests that were written with this forward
> compatibility in mind.
>
> I would be happy to transform this into an RFC if you think it would be
> appropriate.
> ----
>
> Any feedback would be greatly appreciated.
>
> Best regards,
> Pedro Magalhães
>
>
>
>