Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117704
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6E1A63BF-35BC-4921-8D4B-7A9A6EE2775B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Mon, 9 May 2022 12:27:36 +0100
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAMrTa2G6jqiUejTM2WCBmGRk=r34S81cC9AFvcPpc1CxBv-Jgw@mail.gmail.com>
 <B09FDF7D-FCDC-4D9D-BFE7-A60307222D27@craigfrancis.co.uk>
 <CADyq6sJ__0g1mrMtmSLjpJOz=KQhf+jHrQZH9O_Ch=qN0uzKgw@mail.gmail.com>
 <CE61E824-0106-46E3-8630-8A668E992FC0@craigfrancis.co.uk>
 <F915D2AA-BBE5-4B20-81F1-9260DFFA6377@dafert.at>
 <d98f7000-1ee9-0e43-b4e5-8bba19d20354@alec.pl>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <d98f7000-1ee9-0e43-b4e5-8bba19d20354@alec.pl>
Message-ID: <61DD2793-12BF-4829-9915-E6A86BAB98F3@craigfrancis.co.uk>
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

--Apple-Mail=_6E1A63BF-35BC-4921-8D4B-7A9A6EE2775B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 7 May 2022, at 18:16, Aleksander Machniak <alec@alec.pl> wrote:
> On 07.05.2022 13:29, Mel Dafert wrote:
>> It is exactly user-defined functions that this RFC introduces =
breakage for.
>> The behaviour to throw on null in user-defined functions exists since =
PHP
>> 7.0, and is being relied on. Changing these now would introduce =
behaviour changes
>> that are harder to find than new type errors.
>> Using strict typing isn't an option either/would be just as much work =
as auditing
>> the changes this would introduce.
>> It may be that user-defined functions should have accepted null to =
begin with in
>> your opinion, but that still makes it a breaking change now.
>=20
>=20
> Indeed. I suggest to add a note to "Backward Incompatible Changes" =
section of the RFC. This changes the contract, but does not throw new =
errors in existing code.


Thanks Aleksander,

While I'm emailing Mel off-list about a more realistic example, I've =
added a simple example to demonstrate a BC break:

=
https://wiki.php.net/rfc/null_coercion_consistency#backward_incompatible_c=
hanges =
<https://wiki.php.net/rfc/null_coercion_consistency#backward_incompatible_=
changes>

```
function my_function(string $my_string) {
  var_dump($my_string);
}

try {
  my_function('A');   // string(1) "A"
  my_function(1);     // string(1) "1"
  my_function(1.2);   // string(3) "1.2"
  my_function(true);  // string(1) "1"
  my_function(false); // string(0) ""
  my_function(NULL);  // Throw Type Error
} catch (TypeError $e) {
  // Do something important?
}
```

I believe the example Mel is looking at involves a function that should =
return an integer; and later, a second function should only be run when =
the returned value is `!=3D=3D 0` (not `!=3D 0` or `> 0`, due to "style =
guides telling people to unconditionally prefer triple equal")... that's =
all working fine, but sometimes the first function can return NULL (I =
assume that indicates a problem), where it's useful to have the second =
function throw an exception when this happens (so no more processing =
happens, and it can be investigated). While I think there are better =
ways of handling this, I'll work with Mel to get this example into my =
RFC.

Personally I think these are quite unusual, and don't match the size of =
the BC impact we face when internal functions (that have been accepting =
and coercing NULL since, well, forever) start throwing fatal type errors =
in 9.0.

Craig


--Apple-Mail=_6E1A63BF-35BC-4921-8D4B-7A9A6EE2775B--