Nikita, It is _always_ better to have more specific exceptions when it makes sense. In this case, we need to do it to maintain BC.
One use-case that wasn't covered in the RFC, is the use of argument unpacking with too few elements in the array/traversable — whereby you would want to guard specifically for this condition, and handle it in a non-generic way. WRT to the internal functions, you were the person to bring up the behavior of internal functions: > Problem: We already use TypeError for this for internal functions. If we want to introduce an extra exception for this, lets use it for internal functions as well. In that case we should probably go with something that applies not just to too few arguments, but also to too many. During which I noticed the discrepancy with the array functions. - Davey On Thu, Aug 25, 2016 at 12:45 AM, Nikita Popov <nikita....@gmail.com> wrote: > On Aug 24, 2016 9:55 AM, "Davey Shafik" <da...@php.net> wrote: > > > > Hi all, > > > > Given this thread: http://externals.io/thread/233 > > > > I'm not happy with the state of this going into RC1 next week, and > without > > changes (such as the patch I provided), I would like to revert this > change > > and leave it for 7.2. > > > > My patch will _retain_ BC for internal functions with non strict_types > > (except for the error message, which can be reconciled), and for > functions > > that previously threw a TypeError, ArgumentCountError is a subclass so BC > > is preserved there also. > > > > The issue is that the array functions that do this argument count > checking > > themselves and still issue a warning, regardless of strict_types. > > > > We can leave the original behavior for array functions, but they then > > differ from other internals functions. > > > > It is a BC break for userland functions (as per the RFC), throwing an > > ArgumentCountError regardless of strict_types. > > > > At this point, we _must_ come to consensus by Monday to get it into RC1 > (if > > there are changes needed) or we should remove it from 7.1. Also, I would > > like someone more experienced to review my patch. > > > > - Davey > > I have some trouble understanding what the issue is here. The mentioned > RFC affects only userland functions, so the non-standard behavior of some > array functions shouldn't matter. > > Personally I am entirely indifferent as to what exception gets thrown when > too little arguments are passed -- this is a type of error that should not > be caught by anything but catch-all handlers. > > Inability to provide a more specific exception should not be a blocker for > this, especially as this is beyond the scope of the original RFC. > > Nikita >
