Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:102840
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.174 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAKOZhE8c6L3bTFtne7MPTH0Qf3kfKYYnby71uSUEU75EsfAbgA@mail.gmail.com>
References: <CAKOZhE8c6L3bTFtne7MPTH0Qf3kfKYYnby71uSUEU75EsfAbgA@mail.gmail.com>
Date: Mon, 16 Jul 2018 13:14:03 +0200
Message-ID: <CAF+90c8FHMoAnKyxu4Kfanmr1omqQOvtLU8W2zgvQDLEtkx6zA@mail.gmail.com>
To: Zeljko Mitic <mitke013@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000059328f05711bed88"
Subject: Re: [PHP-DEV] [RFC] Optional typehint check for parameters
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000059328f05711bed88
Content-Type: text/plain; charset="UTF-8"

On Sun, Jul 15, 2018 at 9:39 PM, Zeljko Mitic <mitke013@gmail.com> wrote:

> PHP is dynamic language and each typed typehinted parameter has to be
> checked every time. I am suggesting new php.ini value "typecheck.enable =
> 1" which can be turned off.
>
> Example:
> with default php config, a code like this would check each member of $users
> array:
>
> function demo(User ...$users) {}
>
> but with "typecheck.enable = 0", same code would be treated like it was
> written this way:
>
> function demo(...$users) {}
>
> Basically, php would simply *ignore* typehints and work like they are not
> there.
>
> It would be programmers responsibility to send correct values but people
> using typehints are not those still learning the basics.
>
> Just like it is programmers responsibility to restart php-fpm when using
> opcache.validate=0, it would be theirs responsibility to send correct
> values. Any decent IDE would mark errors for wrong parameter type and with
> tools like phpstan, it is almost impossible to make one. Only development
> computers would need to have this checks turned on.
>
> This creates no BC problems as it is a new feature. Given that typechecks
> can be turned off, all existing programs would benefit from extra speed.
>
> I am sending this mail by following rules from
> https://wiki.php.net/rfc/howto . I don't have any knowledge of php
> internals so unfortunatelly, I can't help with this. I at least hope
> someone will take this RFC into consideration.
>

Independently of the question of whether we want to do this at all or not,
there is a technical difficulty here: While most type checks are just that,
scalar type checks (in particular in coercive mode) may perform type
conversions. You pass "42" to a parameter accepting int and the parameter
will become 42.

Just disabling type checks completely would mean that the function now
receives "42", which actively violates the type contract (even though the
code was completely error free with enabled type checks).

How do you propose to handle these cases?

Nikita

--00000000000059328f05711bed88--