Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113944
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>
 <CAAKU0ukNDzCQ3hBCHSJZFetZbJnijE-KntbmZuV-6DDvvJZCDg@mail.gmail.com>
 <C131E912-F394-4F2A-A80D-C95EE2DB3DA6@trowski.com> <CAEPJdu==ggHpe0imzLd3ETZw3gED8sQsnTHuKh=AaKom+0j5kQ@mail.gmail.com>
 <CAEPJdunXtJaWHrfMdiPf0qGzajmDfObGYnYb+0VaSWNWDsAJkA@mail.gmail.com> <CAKuGYLQbuxFWs=WO28SoZh4nXF-EySQg2cYPqxMzjcGhoyi7Ug@mail.gmail.com>
In-Reply-To: <CAKuGYLQbuxFWs=WO28SoZh4nXF-EySQg2cYPqxMzjcGhoyi7Ug@mail.gmail.com>
Date: Sat, 3 Apr 2021 23:28:41 -0300
Message-ID: <CAEsg9X1bXS1ucJxWs1y39=zo3-Vyp6sT0SgS3MiQ7pgkQjY7GQ@mail.gmail.com>
To: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000aff62605bf1c571a"
Subject: Re: [PHP-DEV] [VOTE] noreturn type
From: david.proweb@gmail.com (David Rodrigues)

--000000000000aff62605bf1c571a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Just to spice up the discussion a bit, I will try to give my opinion on
this RFC...

It is very likely that the proposal will be accepted (it is already 33/10),
but I still find the terms "noreturn" or "never" unclear. "noreturn" are
two words together, and I am not particularly a fan of this type of
nomenclature (and it may sound repetitive and strange "return no return"),
while "never" can be ambiguous, it could be read as "never return" (OK) or
"return never" (and it sounds a little strange, I guess).

I saw someone (sorry, I don't remember who) suggesting the term "terminus",
so I thought of an alternative like "terminal". Or, if you still want to
take advantage of a keyword and without losing the meaning, "exit"
(including, it makes absolutely clear what is expected as "return": "return
the exit").

Is there any chance of discussing terms, even if the "never" indication is
winning at the moment? Or did I miss this discussion?

Thanks!


Atenciosamente,
David Rodrigues


Em s=C3=A1b., 3 de abr. de 2021 =C3=A0s 23:07, Matthew Brown <matthewmatthe=
w@gmail.com>
escreveu:

> On Sat, 3 Apr 2021 at 12:30, Benjamin Eberlei <kontakt@beberlei.de> wrote=
:
>
> >
> > But adding a new keyword "noreturn" would not be necessary, it could ju=
st
> > be an Attribute as i said in my first e-mail explaining my no-vote:
> >
> > #[NoReturn] // sets a function flag modifying the void behavior
> > public function foo(): nothing {
> >     return; // throws if it reaches this point
> > }
> >
> > This would be closer to what Psalm and PHP-Stan use at the moment if we
> > replace nothing with void.
> >
> > The problem is that "void" is already not perfect, since the callside
> > doesn't care about "return null" with no return type vs "return" + void
> > return type.
> >
> > If we had "nothing" and "null" instead of "void", and we'd say like PHP
> > works, "return;" actually means "return null;", then:
> >
> > function foo(): nothing {
> >     return; // Error: cannot return null from a function that returns
> > nothing.
> > }
> > function bar(): null {
> >     return;
> >     // or return null;
> > }
> >
> > This would more consistently tie into union types where |null is allowe=
d,
> > however on its own it is not: "foo() : null =3D> error".
> >
> > As Levi said, this noreturn/never just perpetuates/amplifies the existi=
ng
> > void mistake and feels off, given that other recent changes to PHP have
> > been more bold, towards removing inconsistencies.
> >
> >
> Clearly comparisons of "noreturn"/"never" to "void" are a bit of a
> minefield, because a number of contributors feel that void was a mistake,
> that its implementation doesn't feel PHP-like.
>
> While I disagree that our proposal is intrinsically connected with the vo=
id
> one =E2=80=93 noreturn/never could work equally well with a "null" return=
 =E2=80=94 our
> proposal does perpetuate one idea behind "void": that PHP can benefit fro=
m
> types found in other languages and type systems, and especially types fou=
nd
> in Hack.
>
> It seems like some of the debate is over whether "noreturn"/"never" is a
> behaviour or a type. If it were purely a behaviour, with no meaning as a
> type, an Attribute would be a much more appropriate location.
>
> It's not just a behaviour, though =E2=80=94 it is a type that follows var=
iance
> rules, and it's a type that PHP can check.
>
> If "void" returns are too much of a distraction, think instead of "object=
"
> return type declarations:
>
> When executing the function
>
>     function returnsObject($o) : object {
>         if (rand(0, 1)) {
>             return $o;
>         }
>     }
>
> Here PHP's engine checks two separate behaviours
>
> 1. when the function explicitly returns, does it return an object?
> 2. does the function ever finish without returning or throwing or exiting=
?
>
> Only the first actually involves a strict type check. The second is a
> generic behaviour check, triggered by the existence of a return type. Thi=
s
> is essentially the same check that we want to trigger with
> "noreturn"/"never".
>
> In fact, as someone recently pointed out, running the following code
> *today* produces similar errors to the ones we propose:
>
>     function php7Redirect() : noreturn {
>         if (rand(0, 1)) {
>             return "bad"; //  Fatal error: Uncaught TypeError
>         }
>         header("Location: https://php.net");
>         exit; // OK
>     }
>
> Our RFC makes this code explicitly legal, and adds covariance. Indeed our
> implementation is small because it correctly treats "noreturn"/"never" as=
 a
> type, allowing us to use the existing return type handling.
>

--000000000000aff62605bf1c571a--