Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127580
Date: Wed, 04 Jun 2025 13:08:38 +0000
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: Ilija Tovilo <tovilo.ilija@gmail.com>, PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Transform void into an alias for null
Message-ID: <LImcn1rVbnVFeZmKvBzp9HLyrASH4q4NFREd3Fp0clqov3H-IG7bkk-PC_-w0vm7zSFiJxpEx49o1iQHGqEGTnfIk2ITiOO3RsQWcVA9gq0=@gpb.moe>
In-Reply-To: <1549c650b0eb4ef61a03a16ecd652e45@bastelstu.be>
References: <6Z2Ysh6MjYp1nyzuB0bTPJc5srObIcMRqt731JaQeXUJk1f_V_Yo2nRn8WvjI7er7pp7pIUE6WYl5pRwvYrtcrd07nCutyAqKPSsZHmrS-Y=@gpb.moe> <CAPyj-LBaE965bh8LtjYsdSa9FEAR=1Pf9+gdW3oGHPKMWaUjDA@mail.gmail.com> <7yeVC5ZrSBpIklddJCWbIApB-mxRpBPasvWFIgoDeXZGXo_kbqdXAdNPEYoe0ajVjA1-P-w2d2JuDdYAN99BShDfnIPiuUqPuB_PbHEdeZ8=@gpb.moe> <1549c650b0eb4ef61a03a16ecd652e45@bastelstu.be>
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 Wednesday, 4 June 2025 at 09:50, Tim D=C3=BCsterhus <tim@bastelstu.be> w=
rote:

> Am 2025-06-03 17:42, schrieb Gina P. Banyard:
>=20
> > 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.
>=20
>=20
> I do not consider `void` to be a type per se, but rather as an indicator
> for the absence of a value.

Well we fundamentally disagree on this topic then,
the RFC that introduced the void type [G1] used as justification for the na=
me void:

> The main reason to choose void over null is that it is the customary name=
 to use for such a return type.
> [...]
> others [PLs] (TypeScript, ActionScript, Swift) do allow void functions in=
 expressions, just as PHP does, by making them *implicitly return some unit=
 type*.
*Emphasis mine*

This reads to me that the authors know that `void` would mean "return unit =
type", rather than "lack of return value".
Moreover, another justification is:

> There's no precedent for it and the name doesn't seem to have been an *is=
sue until now*.
*Emphasis mine*

Which, IMHO, is not the case any more in that there is an issue now with a =
split and nonsensical type hierarchy.

> Basically the difference between a =E2=80=9Cprocedure=E2=80=9D and a =
=E2=80=9Cfunction=E2=80=9D [1].
> That's why it makes sense to me to treat `void` differently from the othe=
r types.

PHP does not, like many modern PLs, make a distinction between a "procedure=
" and a "function", as they are the same thing.
In many PLs a function that returns "nothing" means returning the unit type=
.
And PHP's unit type is null.

Making void and null isomorphic does not prevent people from using either t=
ype name to communicate intent in their source code that this function is "=
procedure" or a "true function".
And if the point of void is for a function to say that it causes side effec=
ts, then adding effect type declarations to PHP would be a better solution,=
 e.g.
```
function foo(): null!my_side_effect1|my_side_effect2 {
   bar(); /* causes my_side_effect1 */
   foobar(); /* causes my_side_effect2 */
}
```

> See also: The `(void)`
> cast which we decided to make a statement rather than an expression that
> always evaluates to `null`.

I do not see how this invalidates my argument nor support yours.

Best regards,

Gina P. Banyard

> [1] https://stackoverflow.com/a/721132

[G1] https://wiki.php.net/rfc/void_return_type#why_call_it_void_and_not_nul=
l