Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:98311 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 49462 invoked from network); 16 Feb 2017 10:14:30 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Feb 2017 10:14:30 -0000 Authentication-Results: pb1.pair.com header.from=flaupretre@free.fr; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=flaupretre@free.fr; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain free.fr from 212.27.42.4 cause and error) X-PHP-List-Original-Sender: flaupretre@free.fr X-Host-Fingerprint: 212.27.42.4 smtp4-g21.free.fr Received: from [212.27.42.4] ([212.27.42.4:50291] helo=smtp4-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 02/A4-01562-48B75A85 for ; Thu, 16 Feb 2017 05:14:29 -0500 Received: from [172.16.0.45] (unknown [158.255.108.131]) (Authenticated sender: flaupretre) by smtp4-g21.free.fr (Postfix) with ESMTPSA id A793919F5D8 for ; Thu, 16 Feb 2017 11:14:24 +0100 (CET) References: Cc: "internals@lists.php.net" Message-ID: <998bc24d-bd6d-76d3-e99b-ef26fcc76eff@free.fr> Date: Thu, 16 Feb 2017 11:14:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation From: flaupretre@free.fr (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=) 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