On Thu, Aug 25, 2016 at 8:12 PM, Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 24.08.2016 at 18:45, Nikita Popov wrote: > > > On Aug 24, 2016 9:55 AM, "Davey Shafik" <da...@php.net> wrote: > >> > >> 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. > > > > 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. > > 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. - Davey
