Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113452
MIME-Version: 1.0
References: <CAKuGYLRjOHWnX24kCVpTUV5DwdVTwcSkakZkZiAmF9YhpGDpVw@mail.gmail.com>
 <75a8a0ec-d988-7712-58b5-88c8061db605@gmail.com> <CAKuGYLR1nNMBNJJXnmmJyDQBf=sFVY0beyv_vT8jBuQMrKpcfg@mail.gmail.com>
In-Reply-To: <CAKuGYLR1nNMBNJJXnmmJyDQBf=sFVY0beyv_vT8jBuQMrKpcfg@mail.gmail.com>
Date: Wed, 10 Mar 2021 14:48:19 -0500
Message-ID: <CAPKYkKxC6VpLXQYs+kopGd_-KPea04UZ7ggcLuCX+WnTKEUNtA@mail.gmail.com>
To: Matthew Brown <matthewmatthew@gmail.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009114d405bd33f3e9"
Subject: Re: [PHP-DEV] [RFC] noreturn type
From: chasepeeler@gmail.com (Chase Peeler)

--0000000000009114d405bd33f3e9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 10, 2021 at 2:22 PM Matthew Brown <matthewmatthew@gmail.com>
wrote:

> On Wed, 10 Mar 2021 at 13:55, Rowan Tommins <rowan.collins@gmail.com>
> wrote:
>
> > I am however slightly confused by what exactly the implementation
> > checks, and when. Is it actually looking for "exit" and "throw"
> statements?
> >
>
> No. Any function annotated with `: noreturn` causes the engine to insert
> a ZEND_VERIFY_NORETURN_TYPE op at the end of the function's operands.
>
> If the Zend engine hits that operand =E2=80=94 which only happens if a th=
row/exit
> *hasn't* been encountered =E2=80=94 it emits a TypeError.
>
> The other thing I'd like to mention is that PHP's implementation of
> > "void" consists mostly of checking that there is no return statement, s=
o
> > a separate keyword of "noreturn" may well cause confusion. I would
> > personally prefer the name "never" for this reason.
> >
>
> If a significant number agree I can add a secondary vote on noreturn vs
> never, but never introduces more of a BC risk.
>
>
I think the difference between void and noreturn is pretty clear, but, if
never is more clear, perhaps neverreturn would be an option that would be
less likely to have BC risks.

Just to throw out some additional ideas, why not two possible types: throws
and exits? Don't have any strong opinions on that, but figured I'd add it
to the discussion.


> Best wishes,
>
> Matt
>


--=20
Chase Peeler
chasepeeler@gmail.com

--0000000000009114d405bd33f3e9--