On 24-2-2024 3:47, Gina P. Banyard wrote:
On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer
<php-internals_nos...@adviesenzo.nl> wrote:
Hi Gina,
I'm not sure a pet-peeve is a good motivation for creating an (I
expect large) breaking change.
The upgrade path, I suppose, would be updating calls to `die`/`exit`
to always have parentheses ? Or alternatively changing those calls to
new throw expressions ?
While that shouldn't be that huge a problem for real codebases (and
would be auto-fixable for adding the parentheses), the bigger problem
I see is the huge amount of teaching materials, tutorials and blog
posts using the versions without parentheses which will now all be
invalidated. I think the pain and confusion that will cause for a
change like this, will linger for years and years.
Smile,
Juliette
I didn't actually know one could do exit;
But like I said, it is extremely easy to support, and the current PR
does support it by hooking into the undefined constant code in the engine.
I don't have strong opinions about removing support for this.
However, I do have strong opinions about changing the type juggling
semantics of exit() to be the usual ones, because the current one is
just confusing.
I am also not sure what would make this a large breaking change, as
changing this from a language construct to a function provides us with
more capabilities.
Ah, I think I missed the part about the syntax both with and without
parentheses still being supported, with the "with parentheses" mapping
to a function call and the "without parentheses" mapping to a
case-insensitive constant.
In that case, I don't see a BC-break and I would regard this as an
"under the hood" change with only a very subtle, minimal impact (the
type checking part if a param is passed).
I do wonder what the documentation would look like as it would leave it
as a function, but one with a special status, in that there is a native
constant of the same name which will enforce the same behaviour.
Smile,
Juliette
