# [RFC][VOTE] Binary String Deprecation - Thread: https://externals.io/message/98131 - Original archive: https://news-web.php.net/php.internals/98131 - Started by mail@pmmaga.net on 2017-02-03T12:47:41+00:00 - Messages: 18 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #98131 — mail@pmmaga.net — 2017-02-03T12:47:41+00:00 URL: https://externals.io/message/98131#98131 Hello internals. After a *very* quiet period of discussion, I have now opened the vote for the Binary String Deprecation. There is a single vote for accepting or rejecting the deprecation. The voting phase will end on 2017-02-20 20:00 UTC. Best regards, Pedro Magalhães --- ## #98132 — mail@pmmaga.net — 2017-02-03T12:53:24+00:00 URL: https://externals.io/message/98131#98132 · In reply to: #98131 Sorry, I missed the link to the RFC on the previous e-mail: https://wiki.php.net/rfc/binary_string_deprecation Best regards, Pedro Magalhães --- ## #98133 — Nikita Popov — 2017-02-03T13:00:42+00:00 URL: https://externals.io/message/98131#98133 · In reply to: #98132 > Sorry, I missed the link to the RFC on the previous e-mail: > https://wiki.php.net/rfc/binary_string_deprecation > > Best regards, > Pedro Magalhães > I'm +1 on this, conditional on the deprecation not being thrown if `token_get_all()` is used. The RFC currently doesn't say whether this is the case. Nikita --- ## #98134 — mail@pmmaga.net — 2017-02-03T13:45:47+00:00 URL: https://externals.io/message/98131#98134 · In reply to: #98133 Hi Nikita, The deprecation notice is not thrown during `token_get_all()` calls. Regards, Pedro > > > > […] > > I'm +1 on this, conditional on the deprecation not being thrown if > `token_get_all()` is used. The RFC currently doesn't say whether this is the > case. > > Nikita --- ## #98289 — Dan Ackroyd — 2017-02-14T18:22:20+00:00 URL: https://externals.io/message/98131#98289 · In reply to: #98131 > Hello internals. > > After a *very* quiet period of discussion, I have now opened the vote for > the Binary String Deprecation. I thought this RFC was likely to pass easily. It's always slightly unfortunate when RFCs are either accepted or rejected by a small margin, particularly when there doesn't seem to have been any voices against it. Please could anyone who voted no, illuminate the rest of us as to why voting no was the correct option? cheers Dan --- ## #98298 — Zeev Suraski — 2017-02-15T12:52:07+00:00 URL: https://externals.io/message/98131#98298 · In reply to: #98289 > -----Original Message----- > From: Dan Ackroyd [mailto:danack@basereality.com] > Sent: Tuesday, February 14, 2017 8:22 PM > To: Pedro Magalhães > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation > > > > […] > > > I thought this RFC was likely to pass easily. > > It's always slightly unfortunate when RFCs are either accepted or rejected by > a small margin, particularly when there doesn't seem to have been any > voices against it. > > Please could anyone who voted no, illuminate the rest of us as to why voting > no was the correct option? I can't speak for others, but for me, it's simply because there's no reason to do it (remove it), while there may/might be a reason to keep it going forward. Keeping it comes at zero cost, and if we ever do need a binary string notation, it sounds more than likely that we'll pick this one. I see no value at removing it even if there's a small chance we'll need it again. I suspect that's why we also saw very little discussion - it's really a non-issue, but it goes both ways - I probably wouldn't add it if it wasn't in, but I don't see the logic in removing it now that it's in. My 2c. Zeev --- ## #98299 — Christoph M. Becker — 2017-02-15T13:11:13+00:00 URL: https://externals.io/message/98131#98299 · In reply to: #98298 > > […] > > I can't speak for others, but for me, it's simply because there's no reason to do it (remove it), while there may/might be a reason to keep it going forward. Keeping it comes at zero cost, and if we ever do need a binary string notation, it sounds more than likely that we'll pick this one. I see no value at removing it even if there's a small chance we'll need it again. For similar reasoning, I abstained from voting. Actually, I'm -0.1 on the deprecation. -- Christoph M. Becker --- ## #98301 — mail@pmmaga.net — 2017-02-15T17:48:46+00:00 URL: https://externals.io/message/98131#98301 · In reply to: #98299 On Wed, Feb 15, 2017 at 2:11 PM, Christoph M. Becker wrote: > > > > […] > rejected by > > […] > voting > > […] > reason to do it (remove it), while there may/might be a reason to keep it > going forward. Keeping it comes at zero cost, and if we ever do need a > binary string notation, it sounds more than likely that we'll pick this > one. I see no value at removing it even if there's a small chance we'll > need it again. > > For similar reasoning, I abstained from voting. Actually, I'm -0.1 on > the deprecation. > > -- > Christoph M. Becker > > Hi all, Thanks for contributing to the discussion. One week ago marked 10 years since the forward compatibility was introduced(5.2.1). This deprecation would allow us to remove them in the future if no implementation ever comes forward. If that implementation ever comes, we could still revert this. I think it's important to mention that this is not a removal, it's only the first step in that direction. I understand the reasoning that "it doesn't hurt". However, I would argue that for someone new to the language, this can potentially be confusing. On the type juggling page, the forward compatibility is mentioned but - AFAIK - nowhere else (also not on the page about the String type). Users are left on their one to figure it out. Searching for "php binary string" leads only to the pack/unpack pages and questions from confused users on StackOverflow. Given how long ago this was introduced, and how it still produces no effect, it seemed like a good time to start preparing for it's removal. Best regards, Pedro --- ## #98303 — Stanislav Malyshev — 2017-02-15T18:35:09+00:00 URL: https://externals.io/message/98131#98303 · In reply to: #98298 Hi! > I can't speak for others, but for me, it's simply because there's no > reason to do it (remove it), while there may/might be a reason to > keep it going forward. Keeping it comes at zero cost, and if we ever Same here. I just don't see what is improved by this removal. To me, it's just disruption (admittedly to a small code base, but still) without any upside. -- Stas Malyshev smalyshev@gmail.com --- ## #98304 — Andrey Andreev — 2017-02-15T19:02:33+00:00 URL: https://externals.io/message/98131#98304 · In reply to: #98303 Hi, On Wed, Feb 15, 2017 at 8:35 PM, Stanislav Malyshev wrote: > Hi! > > > […] > > Same here. I just don't see what is improved by this removal. To me, > it's just disruption (admittedly to a small code base, but still) > without any upside. > > 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? Cheers, Andrey. --- ## #98308 — Stanislav Malyshev — 2017-02-15T20:35:14+00:00 URL: https://externals.io/message/98131#98308 · In reply to: #98304 Hi! > While that's an understandable argument, what happens if we flip it? Is > there any benefit to keeping it? Yes. Not having to change it :) Please note that the barrier for changing something, especially in a mature software product like PHP, especially in a core language, is way way higher than not changing. TO make a change, substantial benefit should be shown. To not make a change, it is enough that this benefit is not shown. -- Stas Malyshev smalyshev@gmail.com --- ## #98311 — flaupretre@free.fr — 2017-02-16T10:14:24+00:00 URL: https://externals.io/message/98131#98311 · In reply to: #98304 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 --- ## #98314 — Dan Ackroyd — 2017-02-16T22:17:50+00:00 URL: https://externals.io/message/98131#98314 · In reply to: #98311 > > the 'binary string' flag may become useful again.... I prefer keeping it. Interestingly, that's why I voted yes. If we want the binary string to be re-purposed in the future it needs to be deprecated in a version before the version that it is re-used. However it could probably wait until there is a clear plan of what to do with strings. cheers Dan --- ## #98315 — Nicolas Grekas — 2017-02-16T22:25:00+00:00 URL: https://externals.io/message/98131#98315 · In reply to: #98314 Actually, there is a very nasty side effect to the "b" prefix: it complicates using the output from token_get_all. You have to be very experienced (i.e. have feel the pain really) to know about this rare edge case - yet it must be dealt with if you want a correct parser in userland. See e.g. https://github.com/symfony/symfony/blob/8f65fc7ec1418593d433e39abb71d3959eb10a0b/src/Symfony/Component/HttpKernel/Kernel.php#L718 in Symfony. It'd have been great if the future would've been freed from this edge case. Too bad it has been rejected. Regards, Nicolas --- ## #98316 — mail@pmmaga.net — 2017-02-16T22:36:28+00:00 URL: https://externals.io/message/98131#98316 · In reply to: #98315 > > > Too bad it has been rejected. > The vote is still open until the 20th. Regards, Pedro --- ## #98317 — Davey Shafik — 2017-02-16T23:07:58+00:00 URL: https://externals.io/message/98131#98317 · In reply to: #98316 I personally think there is value in marking strings as binary using the 'b' even if PHP currently doesn't differentiate, from a developer friendliness perspective. It shows intent, and informs the reader of what to expect if they inspect the value. If anything, the only change I'd make, if possible, would be for `var_dump()` to print it in a readable format (e.g. hex encoded) by default. I don't see any issues with forward compatibility either, any attempt to re-add a 'b' later would exhibit the same behavior it does now, most likely. - Davey > > […] > > The vote is still open until the 20th. > > Regards, > Pedro --- ## #98318 — Nikita Popov — 2017-02-16T23:18:16+00:00 URL: https://externals.io/message/98131#98318 · In reply to: #98315 On Thu, Feb 16, 2017 at 11:25 PM, Nicolas Grekas < nicolas.grekas+php@gmail.com> wrote: > Actually, there is a very nasty side effect to the "b" prefix: it > complicates using the output from token_get_all. You have to be very > experienced (i.e. have feel the pain really) to know about this rare edge > case - yet it must be dealt with if you want a correct parser in userland. > See e.g. > https://github.com/symfony/symfony/blob/8f65fc7ec1418593d433e39abb71d3 > 959eb10a0b/src/Symfony/Component/HttpKernel/Kernel.php#L718 > in Symfony. > It'd have been great if the future would've been freed from this edge case. > Too bad it has been rejected. > I feel your pain... Dealing with binary string lexing is surprisingly subtle. The linked code is a nice illustration, because it handles the binary string case -- but only for b" and not B", which is also valid. I had the same bug in PHP-Parser until recently :/ Nikita --- ## #98333 — mail@pmmaga.net — 2017-02-20T20:05:43+00:00 URL: https://externals.io/message/98131#98333 · In reply to: #98318 Hello all, The voting has been closed and the RFC is declined with 19-13 which is not enough for the 2/3 required majority. Thank you all for voting and for participating in the discussion. Regards, Pedro