Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91184 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 79588 invoked from network); 10 Feb 2016 14:42:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Feb 2016 14:42:31 -0000 Authentication-Results: pb1.pair.com header.from=francois@php.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=francois@php.net; spf=unknown; sender-id=unknown Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.27.42.2 as permitted sender) X-PHP-List-Original-Sender: francois@php.net X-Host-Fingerprint: 212.27.42.2 smtp2-g21.free.fr Received: from [212.27.42.2] ([212.27.42.2:7807] helo=smtp2-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6A/35-12072-55C4BB65 for ; Wed, 10 Feb 2016 09:42:29 -0500 Received: from [127.0.0.1] (unknown [82.240.16.115]) (Authenticated sender: flaupretre@free.fr) by smtp2-g21.free.fr (Postfix) with ESMTPSA id 1A2914B00C4; Wed, 10 Feb 2016 15:39:47 +0100 (CET) To: Dan Ackroyd , Yasuo Ohgaki References: <56A3A01F.1020500@php.net> <56AE8735.4070901@gmail.com> <56AFC8CC.6040201@gmail.com> <56B6680F.6070804@gmail.com> <56B8AFC1.7040100@php.net> Cc: Internals Message-ID: <56BB4C4B.2050900@php.net> Date: Wed, 10 Feb 2016 15:42:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 160209-2, 09/02/2016), Outbound message X-Antivirus-Status: Clean Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets From: francois@php.net (=?UTF-8?Q?Fran=c3=a7ois_Laupretre?=) Le 10/02/2016 15:34, Dan Ackroyd a écrit : > On 10 February 2016 at 07:00, Yasuo Ohgaki wrote: >> Additional comment on this >> >> php > $v=array(1,2,3); >> php > $v .= 'abc'; >> >> I think $v .= 'abc' should not destroy array variable. It's minor issue, though. > > That is the current behaviour. Trying to slip "bug fixes" into RFCs is > a very bad pattern to follow. > > If this should be fixed, it should be done as part of a separate RFC. > >> This insane string assignment raises E_NOTICE. PHP may be better to >> raise E_WARNING for this kind of invalid assignments just like > > François already wrote an RFC for this > https://wiki.php.net/rfc/array-to-string that passed, but apparently > could not be implemented safely, which is a shame. That RFC needs to > be resurrected imo. But again, changing that behaviour needs to be > separate, and not part of this RFC. Sure. All of this is interesting, but out of scope for this RFC. My initial question was just about the fact that empty strings are not handled like other strings, regarding offset assignments (empty strings are silently converted to arrays). Regards François