Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113923
MIME-Version: 1.0
References: <CAKuGYLTStzEuOmhGKDdNdWP2iX_--mqV17jub0LgVPs+O6Bd+g@mail.gmail.com>
 <CAEPJdu=7qoj4ryx3PELYAbBsPFoBOiWZow+AMiw=QpNsRUa6Yw@mail.gmail.com> <CAKuGYLSNKKe_43f97OXxRNdiGQ-dGBYfZUsmdbKfQ=CCUt+tpA@mail.gmail.com>
In-Reply-To: <CAKuGYLSNKKe_43f97OXxRNdiGQ-dGBYfZUsmdbKfQ=CCUt+tpA@mail.gmail.com>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Thu, 1 Apr 2021 13:03:10 -0600
Message-ID: <CAAKU0ukNDzCQ3hBCHSJZFetZbJnijE-KntbmZuV-6DDvvJZCDg@mail.gmail.com>
To: Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] noreturn type
From: internals@lists.php.net ("Levi Morrison via internals")

On Thu, Apr 1, 2021 at 6:59 AM Matthew Brown <matthewmatthew@gmail.com> wro=
te:
>
> On Thu, 1 Apr 2021 at 04:56, Benjamin Eberlei <kontakt@beberlei.de> wrote=
:
>
> > This RFC is using the declaration of the return type, to specify that i=
t
> > never returns. As such noreturn or never is a keyword a long the lines =
of
> > public or final, but it is not a return type.
> >
> > I don't think the argument for potential optimizations in Opcache to
> > eliminate dead code or allow IDEs to hint at dead code are valuable eno=
ugh
> > to justify this change.
> >
>
> By this argument "void" should also be an attribute =E2=80=93 there's no =
reason to
> hint a value that's not being returned.
>
> You'd write functions like
>
>     [\Void]
>     function foo() { ... }
>
> But we don't do that, because the wider programming language community ha=
s
> agreed that "void" is a type, and at compile-time PHP's engine can ensure
> that "void" functions do not return a value.

For what it is worth, it does return a value `null`, which has a type.
Using "void" is outright wrong, a lie told because "we" voted it this
way. Few people seemed to care when I brought this up, but null makes
sense with union types, covariance, etc, which we now have. I'm still
slightly bitter about this, in case you cannot tell.

The [void RFC][1] said:
> There's no precedent for it and the name doesn't seem to have been an iss=
ue until now.

This was disingenuous, as it disregards Swift and Rust, both of which
use a unit type; they just call it () instead of null. These languages
are held in high regard as far as mainstream programming languages go,
but instead we voted to repeat the mistakes of C and company. I
believe Python's PEP 484 for Type Hints was available at this time,
and it uses None when no value is explicitly returned just like PHP
does with null.

But, we decided to do it the wrong way a la C. Let's please not repeat
this mistake. For the record, in C this is an attribute (and
non-standard at that!), not a return type, so this is a particularly
apt comparison.

Please, let's _accurately_ follow type theory and use a bottom type.
According to the [data in Wikipedia][2], the most common names for the
bottom type are:

 1. `never`, used by Elm and Typescript. Note that in Rust the bottom
type is `!` but spelled out in docs as "never".
 2. `nothing`, used by Kotlin, Ceylon, and Scala.

I do not care which name is chosen, but if we are going to have this
sort of thing in the language, it ought to be a bottom type, not an
attribute.

  [1]: https://wiki.php.net/rfc/void_return_type#why_call_it_void_and_not_n=
ull
  [2]: https://en.wikipedia.org/wiki/Bottom_type#In_programming_languages