Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127562
Date: Tue, 03 Jun 2025 15:42:16 +0000
To: Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Transform void into an alias for null
Message-ID: <7yeVC5ZrSBpIklddJCWbIApB-mxRpBPasvWFIgoDeXZGXo_kbqdXAdNPEYoe0ajVjA1-P-w2d2JuDdYAN99BShDfnIPiuUqPuB_PbHEdeZ8=@gpb.moe>
In-Reply-To: <CAPyj-LBaE965bh8LtjYsdSa9FEAR=1Pf9+gdW3oGHPKMWaUjDA@mail.gmail.com>
References: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe> <CAPyj-LBaE965bh8LtjYsdSa9FEAR=1Pf9+gdW3oGHPKMWaUjDA@mail.gmail.com>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Tuesday, 3 June 2025 at 00:48, Ilija Tovilo <tovilo.ilija@gmail.com> wro=
te:

> Hi Gina
>=20
> On Mon, Jun 2, 2025 at 6:28=E2=80=AFPM Gina P. Banyard internals@gpb.moe =
wrote:
>=20
> > RFC: https://wiki.php.net/rfc/void-as-null
>=20
>=20
> After a read, I think I fundamentally disagree with the proposal. It
> says (regarding the status-quo):
>=20
> > * void is not a subtype of a function with a mixed return type
>=20
>=20
> This is laid out as a downside, but I don't think it is. Consider this
> example under the specified behavior:
>=20
> interface MapInterface {
> public function set(string $key, mixed $value): void;
> }
>=20
> class Map implements MapInterface {
> public function set(string $key, mixed $value): void {
> // Store the key/value pair somehow
> }
> }
>=20
> Let's assume the return type `MapInterface::set()` `mixed` instead,
> where the intention is for `set()` to return the previous value, or
> `null` if there was none. This change will go completely unnoticed by
> `Map::set()`, because `void` is now just `null`, which is a subtype of
> `mixed`. This is a bug that would previously have been caught,
> notifying you that you're supposed to return something.
>=20
> Similarly, the code `function foo(): void { return null; }` is now
> proposed to be valid, and I assume the inverse for `void`/`return;` is
> also true. In this example, we now update `Map::set()` to the new
> return type.
>=20
> class Map implements MapInterface {
> public function set(string $key, mixed $value): mixed {
> $oldValue =3D /* Fetch old value somehow */;
> // Store the key/value pair somehow
>=20
> if (!$this->observers) {
>=20
> return; // This line was here before.
> }
>=20
> $this->observers->notify($key, $oldValue, $value);
>=20
>=20
> return $oldValue;
> }
> }
>=20
> Good examples are hard, but imagine `Map::set()` would allow notifying
> a list of observers about changes to the map. Previously, the
> `return;` would have prevented an erroneous call to `notify()` on
> `null`. However, now it is missing the returning of `$oldValue`. This
> is another bug that would previously have been caught. In fact, even a
> missing trailing `return $something;` would not be caught anymore.
>=20
> IMO, these checks are useful enough not to be removed.
>=20
> Please let me know if I'm missing anything.

I must say the examples are not really convincing to me. :)
The compile time warning would *only* be suppressed for case where the retu=
rn type of the function/method is *exactly* null or void,
the moment you have a union type or mixed you would still get the compile t=
ime error.
I realise that I didn't properly describe the behaviour of my PoC implement=
ation in the RFC, apologies for that.

And a type system on its own is never going to be able to catch all impleme=
ntation bugs,
even with dependant and effect types, you can write code that passes a type=
 checker yet not do what is expected.
A type system should be logical, and the fact that the top type (mixed) is =
not a super-type of all types doesn't make any sense.
We *specifically* included null within mixed as having a proper top type is=
 required, even if many people would have preferred it to exclude null and =
just use ?mixed if you wanted "everything".

As said to Anton, PHP does not have the concept/capability of "not returnin=
g a value" (unless you throw/exit)

Final small cheeky note, we don't warn/error in other cases where we detect=
 dead code, we let the optimizer get rid of them, is this something we shou=
ld warn about?

Best regards,

Gina P. Banyard