Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93936
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.50 as permitted sender)
To: internals@lists.php.net
References: <BY2PR0201MB178408B05E7A793C6470C7A9BF5C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Message-ID: <917d2186-e4c2-a2ab-b23b-624cb8973112@gmail.com>
Date: Mon, 13 Jun 2016 14:07:07 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <BY2PR0201MB178408B05E7A793C6470C7A9BF5C0@BY2PR0201MB1784.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] Replace "Missing argument" warning with
 "Too few arguments" exception
From: rowan.collins@gmail.com (Rowan Collins)

On 06/06/2016 08:22, Dmitry Stogov wrote:
> Hi,
>
>
> This mini RFC has been moved to "Voting" state.  Voting
> began on Jun 6 and will close on June 16.
>
> You can find the full RFC at: https://wiki.php.net/rfc/too_few_args
>


Hi,

The more I think about this RFC, the less I agree with it being included 
in 7.1.

I realise this is now officially late in the approval process to raise 
these points, but note that the discussion period was just 5 days, when 
a language change would normally require 2 weeks.



On the one hand, it doesn't stop a function's author from having to 
check for missing data, as claimed.

As far as the receiving function is concerned, there is no difference 
between a missing parameter and an explicit null; both are currently 
allowed by default, and both are prohibited if a (non-nullable) type 
hint is present. Any unhinted parameter can accept nulls, so a defensive 
programmer must always check for them.

Like strict_types mode, the change only actually affects the *caller* of 
the function. We can posit two types of user: those who read and fix all 
warnings, and those who ignore them. To a user who reads all warnings, 
this change makes no difference: they were already avoiding this 
behaviour by fixing the warnings. To a user who doesn't, it is a 
breaking change, which may prevent their application from running on PHP 
7.1.



On the other hand, there is a real risk of people delaying adoption of 
7.1 because of these new errors.

On the face of it, it seems like it would be trivial to fix code not to 
trigger this error, but there are more complex cases, such as callbacks. 
A simple example:

function foo($a, $b, $mode) { }
$callback = 'foo';
$data = [1,2];
usort($data, $callback);

This code will run under all current versions of PHP, but throw an Error 
under 7.1 if this RFC passes. If the definition of foo(), the origin of 
$callback, and the usort line, are all in different places, it may not 
be trivial to determine the correct fix for this.

There is an assumption from those who have spoken in favour of the RFC 
that such warnings will rarely be ignored in real world code, and 
therefore nobody will actually be affected by this. Here, we are 
pitching anecdote against anecdote; my feeling is that many people 
routinely ignore warnings, and will consider their code to be "running 
fine" under 7.0, then see it "crash" under 7.1.



I was pleased when the "minor versions will retain BC" policy was 
adopted, because I thought it would avoid the problems we had with PHP 
5.3 and 5.4, and allow wider adoption of the latest version. Allowing 
this change would mean that promise has been broken.



Regards,
-- 
Rowan Collins
[IMSoP]