Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104178
MIME-Version: 1.0
References: <CAF+90c9E6O-12fKKY_kb5b_LvXgODbPpC73TNro+XpMewndT2Q@mail.gmail.com>
 <CAFPFaMLY6kebV9d=J4ZxGc5-gm2X=57knbaOnoum1FzpZccMvQ@mail.gmail.com>
In-Reply-To: <CAFPFaMLY6kebV9d=J4ZxGc5-gm2X=57knbaOnoum1FzpZccMvQ@mail.gmail.com>
Date: Tue, 5 Feb 2019 14:29:17 +0100
Message-ID: <CAF+90c-NnvWoK=yx7_=b2J77JbdS+x09ETOJFXCVmGL1NjAwsA@mail.gmail.com>
To: Girgias <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a9d8170581259934"
Subject: Re: [PHP-DEV] [RFC] Consistent type errors for internal functions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a9d8170581259934
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 5, 2019 at 1:23 PM Girgias <george.banyard@gmail.com> wrote:

> On Tue, 5 Feb 2019 at 12: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 actually
>> start specifying type information in arginfo without fear of breaking
>> things.
>>
>> Regards,
>> Nikita
>>
>
> I'm all for it but what is the scope of the RFC?
> Is it all core functions, bundled extension functions, or all extension
> functions?
>

It affects all internal functions using the zpp APIs, which covers pretty
much all core functions, bundled extension functions and third-party
extension functions.


> Also does this means that there will be argument type hinting in core
> functions that
> could be found out via reflection?
>

Not as a direct result of the proposal, but the RFC does remove the big
blocker for it. Once it lands we need one more change (don't actually
verify arginfo types for internal functions to avoid double type checking),
and then we can start adding the necessary type information. That will also
take some work, as we have many functions, but it's something everyone can
help with.

Nikita

--000000000000a9d8170581259934--