Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123445
Date: Tue, 28 May 2024 12:04:48 +0000
To: Claude Pache <claude.pache@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a standard function
Message-ID: <fUzj4SCm0iaXAG1dtJYMKd4twPMkZMJ_Bc3Ws6evjBVlzyUiu1clUpIcW9L3HuICjzfYdNIWyXSMBrTNp1QFNvLQRAU9BUwbjrdRracdAGE=@gpb.moe>
In-Reply-To: <43619F54-863D-4D6F-B507-B6256058F4B0@gmail.com>
References: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe> <43619F54-863D-4D6F-B507-B6256058F4B0@gmail.com>
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 Monday, 27 May 2024 at 19:10, Claude Pache <claude.pache@gmail.com> wrot=
e:
> Hi Gina,
>=20
> It is ok, for `exit` to be wired to a function. However, the paren-less `=
exit` syntax is absolutely reasonable and should be kept in the long term (=
more on this below). It is true that your proposal doesn=E2=80=99t remove t=
he paren-less form, but the implementation (a hack around constant evaluati=
on) strongly suggests that it is desirable to deprecate it in the future (h=
ey, it is even the very first item of the `Future scope` section). Therefor=
e, I think it is preferable to keep proper parsing rules for `exit`.
>=20
> Now here is why I think that `exit` syntax without parentheses is reasona=
ble. For me, `exit` is a control-flow instruction, saying to terminate the =
program, just like `return` terminates a function or `break` terminates a l=
oop. I don=E2=80=99t care about implementation details, whether it is imple=
mented as invoking a never-returning function, or as throwing a hidden exce=
ption, or whatever. The fact is, in typical use:
>=20
> `php header("Location: /somewhere/else.php"); exit;`
>=20
> I would consider an oddity and useless noise to put empty parentheses aft=
er a bare `exit`, just as I wouldn=E2=80=99t consider to put empty parenthe=
ses after a bare `return`.
>=20
> (BTW... I wouldn=E2=80=99t describe a bare `yield` (equivalent to `yield =
null`) as =E2=80=9Cconstant=E2=80=9D evaluation, even if it may be found in=
 same positions as a =E2=80=9Creal=E2=80=9D constant.)
>=20
> =E2=80=94Claude

Adding something to Future Scope does not mean I will pursue this, this is =
just a possible direction that can be done and needs to be argued on its ow=
n merits.
And frankly I have no intension on pushing this, I would _rather_ remove su=
pport for passing strings to exit() than removing the paren-less form.

It should be noted that in other programming languages, exit() is a functio=
n that requires an argument for the status code.
So I don't think of it as a control-flow instruction (because I don't see t=
erminating something as control flow) but if that's how you see it fine.
If that's the only reason for keeping proper parsing rules, I'm not sure wh=
ether that's worthwhile IMHO.


Best regards,

Gina P. Banyard