Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:96758 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 42128 invoked from network); 7 Nov 2016 13:03:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Nov 2016 13:03:59 -0000 X-Host-Fingerprint: 137.50.157.186 oa-edu-157-186.wireless.abdn.ac.uk Received: from [137.50.157.186] ([137.50.157.186:19726] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/7C-33116-DBB70285 for ; Mon, 07 Nov 2016 08:03:58 -0500 Message-ID: <2E.7C.33116.DBB70285@pb1.pair.com> To: internals@lists.php.net References: <7A.F8.33116.E57DF185@pb1.pair.com> <2B.5B.33116.CD460285@pb1.pair.com> Date: Mon, 7 Nov 2016 13:03:53 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 137.50.157.186 Subject: Re: [PHP-DEV] Re: Binary string forward compatibility removal From: ajf@ajf.me (Andrea Faulds) Hi, Joe Watkins wrote: > 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. Well, that's not quite fair. b"" and "" are equivalent, u"" wouldn't be. It's only as useless as, say, the unary + operator. I can imagine it being used to be explicit about using a binary string. In any case, I don't think that it not doing anything that a bare string literal does makes enough of a case to remove it. It's going to bite some people if we remove this, and for what gain? > > 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. The two are related, if we're to get rid of one, we should get rid of both. If there's BC concerns for (binary), I suspect there's also breakage for b"". (binary) is also “useless”, insofar as you could just use (string). Thanks. -- Andrea Faulds https://ajf.me/