Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105849
MIME-Version: 1.0
References: <CAF+90c98bNMCgKLpTVpefyarJNb_KF0WLFbuC1cR9dhpdk_qZQ@mail.gmail.com>
In-Reply-To: <CAF+90c98bNMCgKLpTVpefyarJNb_KF0WLFbuC1cR9dhpdk_qZQ@mail.gmail.com>
Date: Thu, 6 Jun 2019 13:48:51 +0200
Message-ID: <CAL0xaBHhshL+8rFRUerXz4dsKye71TzevZjjdOpMMGFWEJoRrA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ce9b74058aa64d29"
Subject: Re: [PHP-DEV] Handling of null arguments to internal functions
From: arvids.godjuks@gmail.com (Arvids Godjuks)

--000000000000ce9b74058aa64d29
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=D1=87=D1=82, 6 =D0=B8=D1=8E=D0=BD. 2019 =D0=B3. =D0=B2 10:55, Nikita Popov=
 <nikita.ppv@gmail.com>:

> Hi internals,
>
> The https://wiki.php.net/rfc/consistent_type_errors RFC resolved one of
> the
> big differences in argument handling between internal and userland
> functions. This change allowed us to add return type information (availab=
le
> through reflection) to internal functions, something that Gabriel Caruso
> has been working on.
>
> During the discussion of that RFC, Andrea raised another important
> difference: User functions do not accept null for a typed argument, unles=
s
> it is explicitly nullable (through ?Type or a null default value). This i=
s
> independent of whether the type is scalar (int and array both reject null=
)
> and also independent of strict_types.
>
> For internal functions on the other hand, in weak typing mode, null will =
be
> accepted to scalar arguments and coerced to the respective type. For
> example strlen(null) becomes strlen('') becomes 0, without emitting any
> diagnostics.
>
> More precisely, this is a difference between two different argument
> handling approaches, arginfo (used by userland, forbids null) and zpp (us=
ed
> by internal, allows null). As we would like to also use arginfo for
> internal functions (as it is available through reflection, while zpp is
> not), we need to resolve this discrepancy in some way.
>
> The "correct" thing to do would be to forbid passing null to non-nullable
> arguments for internal functions / zpp as well, making behavior fully
> consistent. I've created https://github.com/php/php-src/pull/4227 to
> prototype this and see how the test impact looks like.
>
> However, I think there will be a lot of fallout from this change. When
> running this patch against the Symfony test suite, I get many thousands o=
f
> deprecation warnings (though many with the same root cause). In some case=
s,
> it's a matter of us not marking arguments as nullable that likely should
> be, e.g. I was able to remove a slew of deprecation warnings by making th=
e
> $pattern argument in NumberFormatter/IntlDateFormatter nullable.
>
> This is what I originally wanted to propose here, but after seeing the
> impact this has (relative to, say, changing =3D=3D semantics) it might no=
t be a
> good idea.
>
> If we don't want to do that, then we should start accepting null for
> scalars for internal functions in arginfo as well. It will resolve the
> arginfo/zpp discrepancy, but will leave the divide between
> internal/userland functions.
>
> Thoughts?
>
> Regards,
> Nikita
>

Hello Nikita,

as a user-land dev and in general looking at where I would like for PHP to
end up long-term, I think the first one is a better solution, though quite
a bit more painful to do and longer-term to implement due to the amount of
work involved.

My reasoning is JIT - as things go forward, we probably are going to start
to see some things get implemented in PHP instead of the C core (*caught*
PDO) and that might lead to some strange situations if the argument
handling is going to be inconsistent between these two worlds. But
consistency, in general, would be a nice change of pace so you don't have
to keep in mind that there are slight differences in behaviour depending on
what you call - a built-in function or a userland one.

My 0.02$,
Thanks.

--=20
Arv=C4=ABds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

--000000000000ce9b74058aa64d29--