Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104228
MIME-Version: 1.0
References: <CAF+90c9E6O-12fKKY_kb5b_LvXgODbPpC73TNro+XpMewndT2Q@mail.gmail.com>
 <5c5a1f01.1c69fb81.5339.b8b7SMTPIN_ADDED_MISSING@mx.google.com>
In-Reply-To: <5c5a1f01.1c69fb81.5339.b8b7SMTPIN_ADDED_MISSING@mx.google.com>
Date: Wed, 6 Feb 2019 09:22:47 +0100
Message-ID: <CAF+90c-taWU597A4G9HZLfj904mtEfdxbAL0aWa8b7mdZ2=Qcw@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000070fa8d0581356f31"
Subject: Re: [PHP-DEV] Re: [RFC] Consistent type errors for internal functions
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000070fa8d0581356f31
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 6, 2019 at 12:40 AM Andrea Faulds <ajf@ajf.me> wrote:

> Hi Nikita,
>
> Nikita Popov wrote:
> > 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
>
> I like this proposal. IMO PHP's E_WARNING + NULL is the worst of its
> =E2=80=9CKeep Calm and Carry On=E2=80=9D (sorry) behaviours, it would be =
nice to get rid
> of it for good, rather than just in the comfy world of strict_types=3D1.
>
> > 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.
>
> Regrettably, as I pointed out to you via another channel, that idea also
> faces the problem of the other deliberate inconsistency I am responsible
> for in userland scalar type declarations, namely that the non-nullable
> variety of those reject null as a valid value, unlike internal functions
> which will happily coerce it. It's funny to mention this here, as the
> E_WARNING + NULL behaviour your RFC would drop was a primary
> justification of mine for making NULL special here. Unfortunately it's
> not the only case, I'm sure uncountably much PHP code relies on things
> like strlen($_GET['nonexistent']) working=E2=80=A6 but I digress.
>

Right, thanks for pointing that one out. We could either resolve this by
making the behavior of internal functions consistent with user-defined ones
here (which would be another BC break for another RFC), or alternatively we
could make the arginfo handling for internal functions consistent with zpp.
I already mentioned previously that we'll have to drop arginfo type checks
for internal functions if we want to get serious about adding those type
annotations, otherwise we'd be paying for duplicate type checks. That would
leave us with just the zpp behavior, which allows null for scalars. It's
not great, but probably much better than functions either accepting null or
not depending on whether they use arginfo.

Nikita

--00000000000070fa8d0581356f31--