Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124685
Date: Tue, 30 Jul 2024 12:30:50 +0000
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] [VOTE] Transform exit() from a language construct into a standard function
Message-ID: <ZSpcYknK0LK2eKQgO6FM8LnZDvRY8bqQNLXjA46EoCqCdrqUS_r2IOVAEgc0BwFJS25emgnQHsULJNjAIpbs0PzBTaVdR9iIuRdQ-jcGvCc=@gpb.moe>
In-Reply-To: <15bb76a0-cbd7-4145-b429-76d424755106@gmx.de>
References: <WAN6ETlWt7JfcVoyeYfY_F_eLE6WzQa87F7yi8SHISmyktMYx7YcA6oG5dis3gFeI36VBjSfjGw4AT6psFFDXEUNRrvKRRn4LxfdCxFBccw=@gpb.moe> <15bb76a0-cbd7-4145-b429-76d424755106@gmx.de>
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 Tuesday, 30 July 2024 at 13:47, Christoph M. Becker <cmbecker69@gmx.de> =
wrote:

> Hi Gina!
>=20
> On 30.07.2024 at 11:49, Gina P. Banyard wrote:
>=20
> > I have just opened the vote for the "Transform exit() from a language c=
onstruct into a standard function" RFC:
> > https://wiki.php.net/rfc/exit-as-function
> >=20
> > The vote will last for two weeks until the 13th of August 2024.
>=20
>=20
> As userland PHP developer, I always regarded `exit` as a control flow
> instruction (quite similar to `break`), and as such I'm not really in
> favor of converting it to a proper function (especially since it is not,
> because the parantheses could be omitted).

You are not the first person to mention this.
I don't have any plans on doing anything else to exit, but I never really c=
onsidered it to be a control flow instruction, but that is maybe just me.

>=20
> Would that RFC imply that I would need to write `\\exit` or have a `use e=
xit` clause to avoid dynamic namespace lookup? If so, I would be even
> less in favor of that change.

No, since the new implementation where the token is preserved this is not n=
eeded.
You cannot define the function in a namespace, nor disable it, nor use it a=
s a goto label.
The one benefit of having it become a proper function which can also be use=
d as a statement is:
- Using named arguments
- Passing it to callable parameters
- Usual type juggling semantics

>=20
> I do understand your point about the type juggling semantics, but I
> might have addressed that differently. I almost always use `exit`
> without argument (and if, only with an int), and `die` always with a
> string (and only for quick experiments), and I figure that this might be
> what most contemporary code does (at least, I hope that the
> `do_something() or die()` times have long gone). As such, having `exit`
> and `die` as alias could be changed, sticking with `exit` as a control
> flow instruction, and having `die` as proper function (which could even
> be implemented in userland), where exit would allow an optional int
> argument (like `break`), and die() a required string argument. Of
> course, this would be a much bigger BC break, but it seems to me the
> cleaner solution.

This might be a good idea in the long term to properly split exit and die a=
nd have them take only integers and string respectively,
but I am not going to personally bother with this, even if I think this is =
a good idea.


Best regards,

Gina P. Banyard