On Saturday, 24 February 2024 at 11:46, Kamil Tekiela <tekiela...@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.
>
> 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.
>
> This is reminiscent of Python 2 -> 3 migration with the print
>
> 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.
>
> 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 setting.
It can be a function AND NOT be able to define a custom exit()/die() function
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
userland, except AST-based tools.
And people have suggested a way to not break AST tools, by transforming exit;
into exit(); at compile time.
I also find it extremely weird that it is acceptable that exit() has its own
completely weird type juggling semantics that break user expectations,
when it looks like a function. What is the reason to force users to know and
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 error.
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
juggling context.
I realize that I probably should have just spent time writing an RFC and doing
the discussion directly, as I'm effectively laying out the arguments why we
should do this in an email.
Best regards,
Gina P. Banyard
