Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104453
MIME-Version: 1.0
References: <CAF+90c9E6O-12fKKY_kb5b_LvXgODbPpC73TNro+XpMewndT2Q@mail.gmail.com>
 <226B512C-02A7-4555-9288-D7A2DA89F068@benramsey.com>
In-Reply-To: <226B512C-02A7-4555-9288-D7A2DA89F068@benramsey.com>
Date: Sun, 17 Feb 2019 17:24:15 +0100
Message-ID: <CAF+90c9uVdc7s9Q2bJtkhGWGkk3J5u9+qenEtNvGhFDL+cg-WQ@mail.gmail.com>
To: Ben Ramsey <ben@benramsey.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000891595058219718c"
Subject: Re: [PHP-DEV] [RFC] Consistent type errors for internal functions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000891595058219718c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Feb 16, 2019 at 6:34 PM Ben Ramsey <ben@benramsey.com> wrote:

> > On Feb 5, 2019, at 05:22, Nikita Popov <nikita.ppv@gmail.com> wrote:
> >
> > Hi internals,
> >
> > I'd like to bring forward the following proposal for PHP 8, which will
> make
> > (zpp) parameter parsing failures always result in a TypeError (rather
> than
> > generating a warning+null, depending on circumstances):
> >
> > https://wiki.php.net/rfc/consistent_type_errors
> >
> > The goal here is to remove one of the inconsistencies between
> user-defined
> > and internal functions, and to put us in a position where we can actual=
ly
> > start specifying type information in arginfo without fear of breaking
> > things.
>
>
> I like this RFC, and from a user perspective, this consistency is
> much-needed.
>
> While warnings don=E2=80=99t affect continued processing, uncaught TypeEr=
rors do.
> What is the recommended upgrade path for users? How will this affect the
> silence @-operator, since I=E2=80=99m sure many users use that to squelch=
 these
> warnings, and they accept the null or false return value as acceptable fo=
r
> processing the rest of the script.
>
> Cheers,
> Ben
>

The recommended upgrade path here is basically "deal with it". If a
codebase does this (intentionally calling functions with invalid params and
suppressing errors) a lot, then it might make sense to register an error
handler that collects all "expected parameter" style errors in a production
environment, to easily identify all code that needs to be fixed. The error
messages have a consistent format, so it should be simple to identify and
eliminate all warnings of this type.

Nikita

--000000000000891595058219718c--