Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122487
Date: Sat, 24 Feb 2024 16:19:56 +0000
To: Kamil Tekiela <tekiela246@gmail.com>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [Pre-RFC] Convert exit (and die) from language constructs to functions
Message-ID: <DVEAwPQE_RcVwSofagQd0KuVlN7mVypDEa7Y-C4i6_6PV5hoWtGH2CYG0azslnDf0bmuKCND71dnQjUp2NEb0Tc1RKLT9yRziH9fKwdT37Q=@gpb.moe>
In-Reply-To: <CAGBsUrc5v47wm96G-xmYBoacPcq97TE0AB4PuAqmXoA0_BP9EA@mail.gmail.com>
References: <dML_nemsGsapovq472mSesuTIKSnJs05IBe1me9cfqf6CALh2GkPjtQ5xJ5OYLyEDAaKYEL-TTouCTYlHlwHQFeMfleMoprZSUZrGRlPnpY=@gpb.moe> <65D94D20.6020702@adviesenzo.nl> <j6DvqHCOyKyOFZ4QdDbYYh7sctrXQVwBGlqRYhvZIUbSjLhKT5xQdn_MZDX9ls44VTw5M925zHZcl9HIj3igqP7O0tO2EDf9f2P38OAQ_p0=@gpb.moe> <65D97FC1.2060203@adviesenzo.nl> <CAGBsUrc5v47wm96G-xmYBoacPcq97TE0AB4PuAqmXoA0_BP9EA@mail.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 Saturday, 24 February 2024 at 11:46, Kamil Tekiela <tekiela246@gmail.com=
> wrote:

> I would actually be against this change. It's a language construct for
> a reason. Functions can be disabled and overridden, but language
> constructs cannot. Exit is supposed to end the script execution
> without any hidden quirks.
>=20
> I don't actually see any good reason to make it a function. You can
> very easily solve your pet peeve in userland by simply wrapping exit
> in a function.
> function my_exit(int|string $value):never { exit($value); }
> You can then pass this function as a callable, redefine it in a
> namespace, and it obeys the normal function type juggling rules.
>=20
> This is reminiscent of Python 2 -> 3 migration with the print
>=20
> statement to a print function change. While you may think you see good
> reasons to make this change, users may see it as trivial and unworthy
> of all the fuss.
>=20
> Unless there is some extremely good reason to make exit a function, I
> would advise against doing it.

I'm impressed by the fact that one seems to ignore what my first email says=
.
It can be a function AND NOT be disabled by the disable_functions INI setti=
ng.
It can be a function AND NOT be able to define a custom exit()/die() functi=
on in a namespace, this is similar to assert() which is also not a language=
 construct (which _can_ de disabled with the disable_functions INI setting)=
.
It can be a function AND NOT have _any_ user facing changes.

The PR is implemented in a way so that there is no BC break at all for user=
land, except AST-based tools.
And people have suggested a way to not break AST tools, by transforming exi=
t; into exit(); at compile time.

I also find it extremely weird that it is acceptable that exit() has its ow=
n completely weird type juggling semantics that break user expectations,
when it looks like a function. What is the reason to force users to know an=
d learn this weird quirk about exit?

Also, comparing this to the Python 2 to 3 migration with print is *totally*=
 disingenuous,
you cannot write: exit 10; or exit "Hello"; if you do, you get a parse erro=
r.
I am not suggesting to make require, or echo, or print be functions as that=
 _would_ be similar to the Python 2 to 3 migration, and I agree that would =
be a bad idea.

This change just makes the language more consistent and removes one type ju=
ggling context.

I realize that I probably should have just spent time writing an RFC and do=
ing the discussion directly, as I'm effectively laying out the arguments wh=
y we should do this in an email.

Best regards,

Gina P. Banyard