Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117682
Message-ID: <B09FDF7D-FCDC-4D9D-BFE7-A60307222D27@craigfrancis.co.uk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_28322B56-20F1-45FE-A889-715F052907D0"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\))
Date: Sat, 7 May 2022 09:38:51 +0100
In-Reply-To: <CAMrTa2G6jqiUejTM2WCBmGRk=r34S81cC9AFvcPpc1CxBv-Jgw@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
References: <CAFv4g+Ej4JbM9SzQ0iU-d8C4T+2XNo=8jnJ1uwfQ=skZZXx9Tg@mail.gmail.com>
 <CAMrTa2G6jqiUejTM2WCBmGRk=r34S81cC9AFvcPpc1CxBv-Jgw@mail.gmail.com>
Subject: Re: [PHP-DEV] NULL Coercion Consistency
From: craig@craigfrancis.co.uk (Craig Francis)

--Apple-Mail=_28322B56-20F1-45FE-A889-715F052907D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 7 May 2022, at 04:45, Jordan LeDoux <jordan.ledoux@gmail.com> wrote:
>=20
> On Fri, Apr 8, 2022 at 10:35 AM Craig Francis =
<craig@craigfrancis.co.uk <mailto:craig@craigfrancis.co.uk>> wrote:
> https://wiki.php.net/rfc/null_coercion_consistency =
<https://wiki.php.net/rfc/null_coercion_consistency>
>=20
>=20
> This RFC seems to be trying to force all PHP developers, regardless of =
what *they* think, to treat null as "whatever the default value is =
within the type context of execution", which is probably the most =
dangerous and bug-prone usage of null in PHP code. This would make it =
almost impossible for most programs to treat null instead as "an =
undefined value which must be explicitly set", which is another usage I =
commonly see in code.


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 =3D round($request->get('my_number'));

Craig


--Apple-Mail=_28322B56-20F1-45FE-A889-715F052907D0--