Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98914
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAESVnVpHyhJN0gOP3pnqwXQBu23WY2G4xFtGqeRvEkLd27s1Dg@mail.gmail.com>
References: <CAESVnVpHyhJN0gOP3pnqwXQBu23WY2G4xFtGqeRvEkLd27s1Dg@mail.gmail.com>
Date: Sat, 29 Apr 2017 22:54:13 +0200
Message-ID: <CAF+90c-Yjg5oPPVPfojBDkH2iSM=zVW+z--O=C2V80j2yPTyvw@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c0344f079cd40054e546451
Subject: Re: [PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c0344f079cd40054e546451
Content-Type: text/plain; charset=UTF-8

On Sat, Apr 29, 2017 at 10:24 PM, Sara Golemon <pollita@php.net> wrote:

> Spinning off a sub-thread:  Does anyone know any particular reason why
> ZEND_ARG_TYPE_INFO is not (barring two windows specific functions in
> standard) used anywhere in core?
>
> Is it?
> 1. Nobody has done the grunt work since 7.0?
> 2. It breaks something? (should only impact reflection AIUI)
> 3. ???
>
> I'd be happy to put in the grunt work on standard, hash, and intl at
> the very least.
>
> -Sara
>

There are a number of reasons why this hasn't happened yet:

1. In weak mode, arginfo type violations throw, while zpp violations warn
and return NULL. As such, adding arginfo types to existing functions is a
BC break.
2. For methods in particular, prior to PHP 7.2, adding arginfo types was
also a BC break. This is no longer the case, as variance is now respected.
3. Arginfo types for internal functions are enforced by the runtime.
Because the types are already checked by zpp, this is an unnecessary
duplicate check. Additionally, type-checking for internal functions is on
the slow-path (to the point there it uses a different opcode). While of
course this doesn't matter for some functions, in other cases type checking
/ parameter parsing is the main overhead of a function (which is why fast
zpp was introduced in the first place). I'm sure we do not want to have
decisions on whether to add or not add arginfo for a particular function
based on whether it would have a significant performance impact.

The solution to these problems is simple: Stop checking arginfo types for
internal functions, just use them for reflection / inheritance checks, but
leave the actual type-checking to zpp. However, this doing this will also
change current behavior due to point (1.), as in weak-mode some type errors
that are currently throwing would be reduced to warn + null. Personally I
don't have a problem with that, as I'd consider this a compatible change,
and it would make type-checking for internal functions consistent.

Nikita

--94eb2c0344f079cd40054e546451--