Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96757
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 74.125.82.43 cause and error)
MIME-Version: 1.0
In-Reply-To: <2B.5B.33116.CD460285@pb1.pair.com>
References: <cdd4edeaf066e73ca2ebdede5d5c535b@pmmaga.net> <7A.F8.33116.E57DF185@pb1.pair.com>
 <CAL=_i_n8NHTR-e5HGFQY1Dm-=+TripTacfOkvKF2r+jq7DriFQ@mail.gmail.com> <2B.5B.33116.CD460285@pb1.pair.com>
Date: Mon, 7 Nov 2016 12:37:47 +0000
Message-ID: <CAL=_i_mZ4yRn1oyD8o154VJRz_FjQnLwv0Xtr3RpF_4U7bYPyg@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e0102e3d0996b8a0540b54afa
Subject: Re: [PHP-DEV] Re: Binary string forward compatibility removal
From: pthreads@pthreads.org (Joe Watkins)

--089e0102e3d0996b8a0540b54afa
Content-Type: text/plain; charset=UTF-8

Afternoon Andrea,

    A case can be made that the binary cast might at some point do
something: "(binary) $ustring"

    There is no case whatever for the literal b prefix, it will *never*
have a function if we are not changing the default string representation.

    If we do adopt a literal prefix for unicode strings, it's going to be
rather confusing to learn that u"" does something and b"" is also
supported, but b"" doesn't, and has never done anything.

    OP: I think this should be split into two RFC's and voted on
separately, it certainly can't be merged by anyone as a PR.

Cheers
Joe



On Mon, Nov 7, 2016 at 11:26 AM, Andrea Faulds <ajf@ajf.me> wrote:

> Hi,
>
> Joe Watkins wrote:
>
>> Morning Andrea,
>>
>>      Who is widely deploying something that does absolutely nothing ?
>>
>
> PHAR uses (binary), or so Pedro's email says.
>
>
>>      The only reason to keep it would be that we are going to change the
>> default representation, as pointed out we're not.
>>
>
> If we were adding it tomorrow, maybe, but `b` and the (binary) cast are
> already here. A high standard must be met for removing features. These
> aren't a security problem, nor a maintenance burden. There's not a good
> case for removing them and breaking backwards-compatibility
>
>
>>      This cannot have been left in for considered reasons, it was just
>> forgotten about.
>>
>
> If it was to be removed, the time to do so would have been right after PHP
> 6's failure. But it's been years now. I'm unconvinced there's a strong case
> to remove it.
>
> Thanks for your reply.
>
> --
> Andrea Faulds
> https://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--089e0102e3d0996b8a0540b54afa--