On Wednesday, 4 June 2025 at 09:50, Tim Düsterhus <t...@bastelstu.be> wrote:

> Am 2025-06-03 17:42, schrieb Gina P. Banyard:
> 
> > 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.
> 
> 
> 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 name 
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 *issue 
> 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 “procedure” and a “function” [1].
> That's why it makes sense to me to treat `void` differently from the other 
> 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 type 
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 effects, 
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_null

Reply via email to