Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105848
MIME-Version: 1.0
References: <CAF+90c98bNMCgKLpTVpefyarJNb_KF0WLFbuC1cR9dhpdk_qZQ@mail.gmail.com>
 <13220937.xxcDpnhvGA@mcmic-probook>
In-Reply-To: <13220937.xxcDpnhvGA@mcmic-probook>
Date: Thu, 6 Jun 2019 12:21:10 +0200
Message-ID: <CAF+90c-LRAmhssxhkCgybw4bdZpAJh7LX6YvF6Q4vhoWDXiUyA@mail.gmail.com>
To: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come@opensides.be>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a11026058aa5135f"
Subject: Re: [PHP-DEV] Handling of null arguments to internal functions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000a11026058aa5135f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 6, 2019 at 12:10 PM C=C3=B4me Chilliet <come@opensides.be> wrot=
e:

> I=E2=80=99m not sure if this is exactly the same topic, but one problem I=
 have
> with how internal functions are handling arguments is how the absence of =
an
> optional argument is treated.
>
> I have stumbled across functions documented as functionname($arg1, $arg2 =
=3D
> NULL) which behaves differently when called as functionname('something')
> and functionname('something', NULL).
> A lot of places in the documentation state "if omitted" about an argument=
.
>
> This is a big problem when several arguments are optional and you just
> want to provide a value for the last one. You cannot know if giving the
> default value for the ones in between will affect the behavior.
>
> Shouldn=E2=80=99t the argument parsing system treat absence the same as t=
he
> default value?
> This is what happens for userland functions.
>

This is a somewhat different but closely related problem. The important
thing to understand is that internal functions do not have a native concept
of a default value. If you see a default value in the documentation, that's
just documentation.

On the implementation side, there is basically three ways in which defaults
are typically handled:
 * Assigning a default to a zpp variable: Omitting the argument and passing
that default value (but not null!) will behave the same.
 * Using a ! specifier: Omitting the argument and passing null will behave
the same.
 * Checking the number of arguments: Omitting the argument and specifying
it may result in differing behavior.

If you see something that is documented as =3Dnull, but does not behave the
same when null is passed, please do report a bug.

The harder question is what to do about cases where the default is
documented as "", and that "" value has abnormal behavior (i.e. is
specially treated in implementation, the behavior does not fall out
"naturally" from the empty string). In that case, I think we should also be
accepting null as a value (independent of strict_types). There are probably
a lot of functions that do this.

Nikita

--000000000000a11026058aa5135f--