Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117684
MIME-Version: 1.0
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAMrTa2G6jqiUejTM2WCBmGRk=r34S81cC9AFvcPpc1CxBv-Jgw@mail.gmail.com> <B09FDF7D-FCDC-4D9D-BFE7-A60307222D27@craigfrancis.co.uk>
In-Reply-To: <B09FDF7D-FCDC-4D9D-BFE7-A60307222D27@craigfrancis.co.uk>
Date: Sat, 7 May 2022 11:01:23 +0200
Message-ID: <CADyq6sJ__0g1mrMtmSLjpJOz=KQhf+jHrQZH9O_Ch=qN0uzKgw@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: Jordan LeDoux <jordan.ledoux@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d3112b05de68389c"
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: ocramius@gmail.com (Marco Pivetta)

--000000000000d3112b05de68389c
Content-Type: text/plain; charset="UTF-8"

Hey Craig

On Sat, 7 May 2022, 10:39 Craig Francis, <craig@craigfrancis.co.uk> wrote:

> Not what I'm going for... but anyway, to get an idea of your position, do
> you think the string '15' should be coerced to a number, or should it fatal
> error as well? e.g.
>
> $my_number = round($request->get('my_number'));
>

Passing '15' for `int` should throw a type error: this is why people
(slowly, steadily) opt into strict types.

I mostly refrained from commenting on this RFC thus far exactly because I'm
already "out of the woods", and I already add strict types everywhere.

Still, when upgrading legacy PHP apps, I would have to deal with the
problem, at which point I prefer looking for type errors in internal
function calls, than looking for changes in null coercion (the one proposed
here) everywhere.

Practically, my idea is:

 * coercion rules are old and well known
 * changing coercion rules around `null` drags in complexity
 * focus should be in migrating to strict types instead

Regardless of the output of this RFC, people upgrading to 8.0 or 8.1 will
already experience BC breaks in internal function input types, and adapt to
them.

This RFC added on top of that further destabilises the upgrade path to 8.2
or other versions (wherever introduced).

For me, this makes the RFC a net negative value for the language and its
consumers, as it adds a problem.

>

--000000000000d3112b05de68389c--