Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121624
MIME-Version: 1.0
References: <CAFv4g+EqzB7whakuN-sr6YL2ih9xhHPzCsvTsEgJKMXBh9H9wQ@mail.gmail.com>
 <5144806E-E21F-4AF8-B9A2-0161561A6B9E@craigfrancis.co.uk>
In-Reply-To: <5144806E-E21F-4AF8-B9A2-0161561A6B9E@craigfrancis.co.uk>
Date: Thu, 9 Nov 2023 17:08:42 +0100
Message-ID: <CAGBsUrfwRExOFZ8dRy0=D9wmKurkj4QBNPvOsmrw7Mh=rjX0mg@mail.gmail.com>
To: Craig Francis <craig@craigfrancis.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009f191c0609ba6b34"
Subject: Re: [PHP-DEV] Re: Passing null to parameter
From: tekiela246@gmail.com (Kamil Tekiela)

--0000000000009f191c0609ba6b34
Content-Type: text/plain; charset="UTF-8"

I don't think that would actually be wise. Automatic casting of null to
other types is a handy feature and deprecating it brings no benefit to
anyone.

Instead, if you want, submit a proposal to reverse the direction. Make it
so that null is cast to an appropriate type in params and return values.
This should only apply in loose-type mode and it would make nullable types
useless. Such a change could also be complicated to implement given how
ambiguous it would be. But if you can outline tangible benefits and write a
PR to show how it would work, I think the community would review the RFC.

But as I expressed before, the current path seems to be the most logical.
Despite the decision to introduce nullable types in PHP 7, which as you
pointed out creates an incompatibility with all other type juggling rules,
this is the cleanest and least ambiguous solution.

As for the negative responses, it's probably because it's been many PHP
versions since the nullable types were introduced. People accepted it and
are generally satisfied with how it works. Only after the last bit was
decided to be fixed in PHP 9.0, you started a discussion pointing out that
on paper it's misaligned with other parts of the language. Just because
null is converted to string in one context and throws an error in another
is not necessarily a bad thing. So unless it's causing some serious
problems for PHP developers or users, I think it's too late to change the
design of the language.

Regards,
Kamil

--0000000000009f191c0609ba6b34--