Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95453 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22828 invoked from network); 26 Aug 2016 10:53:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Aug 2016 10:53:13 -0000 Authentication-Results: pb1.pair.com header.from=cmbecker69@gmx.de; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=cmbecker69@gmx.de; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmx.de designates 212.227.17.20 as permitted sender) X-PHP-List-Original-Sender: cmbecker69@gmx.de X-Host-Fingerprint: 212.227.17.20 mout.gmx.net Received: from [212.227.17.20] ([212.227.17.20:51655] helo=mout.gmx.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id B8/89-34481-89F10C75 for ; Fri, 26 Aug 2016 06:53:13 -0400 Received: from [192.168.2.103] ([79.243.115.246]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LcSWg-1bEeaQ1nza-00jo2Z; Fri, 26 Aug 2016 12:53:08 +0200 To: Davey Shafik References: <7cdd89c1-3fe5-3455-2f03-d5f6648d93d1@gmx.de> Cc: Nikita Popov , PHP internals Message-ID: Date: Fri, 26 Aug 2016 12:53:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:36rMX1zDNyHByZ8ORHfjwK/MTpLnzHfvB0vb8jc3IQdZBirDZFe Pmqat5Lne7n/awccw1+fQ3EwzGA/WrA+7eERntPeSXDpGsR/ivDghC0MSSLo3y9tNFD7ZiW PqXHDfh7Dp/eEhNl0TBu0IN0vQF5GBA5Q/N6H0f2r+rJKK8BjZy43qwU490sFKy0ZDlPi58 659/qgQl+SjXsOhtJc3CQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:tZ6yOTfE/7c=:z79/BCxdS4Ovu+BZDWKXbW oRpkFPXve62c3vCWjpUeg9q/vfyOdKti2qAkfxYXInKS5FX6GbGQXSupai/I9bcmypp3WvH9g 7+ZsUxMYlcFiYf+SkIDTabDiHnJ1CqoXdZElgH0cmJ021jhBWcYcsAFHajWZCMCAGOB7ORz8j nKKiprobrtVNQkQjFOV+61CQKeLskgfRMmryTfZ2u17bb8ReJ+Y8+HeufwPLp27vqHAoX5fuy 3k8USPPGAiU9wn9qyYyVVcv0LkbdERMmuyJq+kYiRBA092UMqdmY4S09oXBA6Np56Q8LswLpQ IZnyu1lkmv1pTJArhQ12GuRZwn6+anTiA9Hixtyz7YlChqrFTS0/vG+qwd7ihuy+HROm82RWd C0K2+lmSpuxzcK7mB9WMUVgx2ANiY8NH0/21ncKUI8UTfXkd4h++fXmILXpbeh5Zu/ZUgLpJw Zbg5dRnL8XpF1BR+fetyJfUYifjhRX6XhDQL6Ui5IU9aEAgGsFRmDnebWlpsUGzmhIiW7K1mr ASyhlgJFVEzmf2qoga6LYKE+/c+ARmhhzJNce4zL7ncGcmzSXdzwgqpjox194LVeviuzoJZR1 IpnkH0OZIclnnFFp3gvzRm7rBgJOtpJjp5q8AvzjkYSFUwBMl+uIIxgbzfwx2Modq6mX4chXU B+wFqd4uQMaz6Rj4aNFE/ch04RSdzSTW01JaykP0JF5DEOl2nTIRMIZC0Mkg95/gvngME97Yr 5RuKqacf7TSy5HFZhaBS79O63kWmuPtrAMRyhrJwuSWXKbDr/+WR+WACrQfo9LlEMn/hXdkxB pAlkqbZ Subject: Re: [PHP-DEV] Reverting "Too Few Arguments Exception" RFC From: cmbecker69@gmx.de ("Christoph M. Becker") On 25.08.2016 at 18:37, Davey Shafik wrote: > On Thu, Aug 25, 2016 at 8:12 PM, Christoph M. Becker > wrote: > >> Indeed, the RFC explicitly claims: >> >> | Behavior of internal functions is not going to be changed. > > This is correct for functions that had the correct behavior before > (everything but array functions). > > I can remove that part of the change — but if we're going to change it, > doing in 7.1 rather than > 7.1 would be best. AIUI, the actual implementation of the too_few_args RFC does what it says, namely to not affect the behavior of internal function at all. The issue you've raised is that we have introduced an inconsistency, because some internal functions (e.g. array_diff) behave differently. If that is so, reverting the too_few_args RFC is out of question, because not changing the behavior of internal functions was intentional, and I assume that everybody who voted on the RFC was aware of that. The inconsistency between internal functions wrt. to too few/many arguments in strict_types mode is not related to the too_few_args RFC at all – we have this as of PHP 7. Fixing this inconsistency as soon as possible might be desirable, but it seems to me that is not even possible in the general case, as not all relevant code is under our control (think of PECL and even "private" extensions). So, even we "fix" the behavior of all bundled internal functions, we still can't claim that *all* functions throw an exception when called with too few or too many arguments in strict_types mode (besides that we easily might miss a few cases). If the docs already make this claim, the docs should be fixed. Finally, I wonder why array_diff(), for instance, even has an explicit check for ZEND_NUM_ARGS() and for Z_TYPE() != IS_ARRAY instead of properly invoking zend_parse_parameters() with "aa+" instead of "+" in the first place? Maybe I'm missing something, but otherwise I would suggest to fix that altogether instead of piecemeal, even if that has to wait until 8.0. -- Christoph M. Becker