Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98915
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 74.125.82.53 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CAF+90c-Yjg5oPPVPfojBDkH2iSM=zVW+z--O=C2V80j2yPTyvw@mail.gmail.com>
References: <CAESVnVpHyhJN0gOP3pnqwXQBu23WY2G4xFtGqeRvEkLd27s1Dg@mail.gmail.com>
 <CAF+90c-Yjg5oPPVPfojBDkH2iSM=zVW+z--O=C2V80j2yPTyvw@mail.gmail.com>
Date: Sat, 29 Apr 2017 16:06:44 -0500
Message-ID: <CAESVnVo9T15uQpM0bMr5sGV9iNtxMpbKTQWstJXXEF+uU0eUPg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] ZEND_ARG_TYPE_INFO usage in core?
From: pollita@php.net (Sara Golemon)

On Sat, Apr 29, 2017 at 3:54 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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.
>
Ugh.... This is why we can't have things.  I'm with you on personally
being fine with not enforcing ARG_INFO hints in the runtime for
internal functions (leaving it to zpp), but as you say that doesn't
work due to #1.  Something for 8.0, I suppose.

-Sara

P.S. Or to quote a common acquaintance: Who uses weak mode? Weak
people, that's who.