Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:95435
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 209.85.216.176 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <CAF+90c_30gzmMXKT0XhZDaTK277uV5edStfka2YVE2ia0xpK9Q@mail.gmail.com>
References: <CANaX5nfGzFsYue8J6yUpNnEYzgUTGj2g-BMWsw1cyahPH=fmmg@mail.gmail.com>
 <CAF+90c_30gzmMXKT0XhZDaTK277uV5edStfka2YVE2ia0xpK9Q@mail.gmail.com>
Date: Thu, 25 Aug 2016 01:56:44 +0800
Message-ID: <CANaX5ndjSTCU4UacZYGY4ZS9jX2EsfdGD_uEM=F8epmTOL9=Tw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1135b2821b3960053ad5017a
Subject: Re: [PHP-DEV] Reverting "Too Few Arguments Exception" RFC
From: davey@php.net (Davey Shafik)

--001a1135b2821b3960053ad5017a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =E2=80=94 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.ppv@gmail.com> wrote=
:

> On Aug 24, 2016 9:55 AM, "Davey Shafik" <davey@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 woul=
d
> > 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 whe=
n
> too little arguments are passed -- this is a type of error that should no=
t
> be caught by anything but catch-all handlers.
>
> Inability to provide a more specific exception should not be a blocker fo=
r
> this, especially as this is beyond the scope of the original RFC.
>
> Nikita
>

--001a1135b2821b3960053ad5017a--