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 <a...@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
>
>
