Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117638
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
In-Reply-To: <e12e12b0-f308-f5ed-d631-92bd4aecaf7a@gmail.com>
Date: Wed, 27 Apr 2022 18:34:36 +0100
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <59030DB4-4E5E-4DF6-AD88-F3665355C467@craigfrancis.co.uk>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <42D0A480-F262-4F72-9C4D-887762A8D800@gmail.com>
 <CAFv4g+ELZ5ZA6zyDFHCJCM6vSy3MFTvEGS9=zo5ZM1izHQWuFw@mail.gmail.com>
 <0b061f28-a087-efd3-8602-424ee03458e0@gmail.com>
 <CAFv4g+HROPPx4hT226ypbKZwM_7nq31jJ6+X+RNq_THZDVrJPA@mail.gmail.com>
 <CALKiJKpPri6A35_g4XqWOG4Zm3XMdz4Z3gRFyMTh9V2TxrbYmg@mail.gmail.com>
 <7DB0A01F-04FB-420D-9025-E027E5DE02F7@craigfrancis.co.uk>
 <c3197e59-3447-0ebc-094b-cb1d67e2314b@gmail.com>
 <19b2d192-fc4a-4122-8a01-54316a50fc1e@www.fastmail.com>
 <CAC5V6ggcpJ7=iYaZbNcRcW=EQQqF6Rtby9RZLEDO00ez3QOG7A@mail.gmail.com>
 <e12e12b0-f308-f5ed-d631-92bd4aecaf7a@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

On 26 Apr 2022, at 21:11, Rowan Tommins <rowan.collins@gmail.com> wrote:
>=20
> On 26/04/2022 17:36, Guilliam Xavier wrote:
>>     function mt_rand(int $min =3D UNKNOWN, int $max =3D UNKNOWN): int =
{}
>>=20
>> documented with two signatures at
>> https://www.php.net/manual/en/function.mt-rand.php
>>=20
>>     mt_rand(): int
>>     mt_rand(int $min, int $max): int
>=20
>=20
> This is actually a really pertinent example: you might expect =
mt_rand(null, null) to give the same behaviour as mt_rand(), but =
actually it will always return 0, because it silently coerces to =
mt_rand(0, 0). That's exactly the kind of unexpected behaviour type =
checking aims to protect against.


First, thanks Guilliam for the examples.

And Rowan, I agree it's a good example, and I've added it to the Open =
Issues.

But I'm wondering, is it only one function? and assuming it's a problem, =
could we use `Z_PARAM_LONG_OR_NULL()` and specifically throw an =
exception when either parameter is NULL, like the `max < min` check? On =
the basis that I'd rather have one extra check for this function, and =
keep NULL coercion working everywhere else (i.e. where it's fine).

As an aside, under the Future Scope:

https://wiki.php.net/rfc/null_coercion_consistency#future_scope

I'd noted some functions that could do with some similar changes, but =
that's more about copying the example of `$separator` in `explode()` and =
the =E2=80=9Ccannot be empty=E2=80=9D error, so NULL or an Empty String =
is rejected (rather than just rejecting NULL).



> There used to be a lot more functions with pseudo-defaults like this, =
but a lot were made to accept null in PHP 8.0. e.g. =
mb_convert_encoding('foo', 'ASCII', null) now acts like =
mb_convert_encoding('foo', 'ASCII') and looks up a run-time default; but =
in previous versions it acted as mb_convert_encoding('foo', 'ASCII', '') =
which is not a valid call.


Thanks, that's another good example, but I'm going to be a pain, and =
would suggest that the specific function was correctly updated to work =
with NULL (and anyone who did pass NULL to that argument, would have had =
the "must specify at least one encoding" error).

Craig