Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:77740 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75020 invoked from network); 1 Oct 2014 19:34:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Oct 2014 19:34:38 -0000 Authentication-Results: pb1.pair.com smtp.mail=mailing@pascal-martin.fr; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=mailing@pascal-martin.fr; sender-id=pass Received-SPF: pass (pb1.pair.com: domain pascal-martin.fr designates 176.31.99.170 as permitted sender) X-PHP-List-Original-Sender: mailing@pascal-martin.fr X-Host-Fingerprint: 176.31.99.170 ks391579.kimsufi.com Received: from [176.31.99.170] ([176.31.99.170:51984] helo=pascal-martin.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B7/10-07377-C475C245 for ; Wed, 01 Oct 2014 15:34:36 -0400 Received: from [192.168.0.3] (home.squalenet.net [82.225.233.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pascal-martin.fr (Postfix) with ESMTPSA id 0BB5440C9F for ; Wed, 1 Oct 2014 21:33:05 +0200 (CEST) Message-ID: <542C5747.9020200@pascal-martin.fr> Date: Wed, 01 Oct 2014 21:34:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: internals@lists.php.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [VOTE] Fix list() behavior inconsistency From: mailing@pascal-martin.fr (Pascal MARTIN) On 25/09/2014 09:42, Dmitry Stogov wrote: > Hi, > > The vote is opened at > https://wiki.php.net/rfc/fix_list_behavior_inconsistency > > Thanks. Dmitry. > Hi, After discussing this RFC with a few other members of AFUP (French UG), we agree *something* should be done, to get to a consistent behavior: either all, or nothing, but not half. Most of us seem to go towards "disabling in all cases" (which indeed means BC-break for those who were using this -- probably not that many), but it seems like no-one will be sad if things end up going the other way around. -- Pascal MARTIN http://blog.pascal-martin.fr/ @pascal_martin