Den 2016-06-13 kl. 15:07, skrev 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,
I would like to add another perspective given that we have a large
migration project going from PHP 5.x to 7.x this autumn. I have a
hunch that we are not alone in that situation.
So for us it makes perfectly sense to have this kind of feature / bug
fix as early as possible. Since it capture an erroneous behaviour, it
helps raising the quality of our code which I see as a clear benefit!
And pardon me, but saying that we can wait until an PHP 8.0 release
that we have no clue about when it will happen sounds in my eyes
a bit to far off. Going that direction means instead that boiler plate
code is needed to catch that exact number of parameters is sent.
So I wonder are we here making a hen out of a feather? But of course
if the release process needs clarifying then do it, but please keep the
feature as is.
Regards //Björn Larsson
PS I could add that if this kind of change had come very late in the 7.x
release cycle I might have been of another opinion.
