Re: [Pre-RFC] Convert exit (and die) from language constructs to functions

From: Date: Sat, 24 Feb 2024 05:33:53 +0000
Subject: Re: [Pre-RFC] Convert exit (and die) from language constructs to functions
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-122486@lists.php.net to get a copy of this message
On 24-2-2024 3:47, Gina P. Banyard wrote:
On Saturday, 24 February 2024 at 01:57, Juliette Reinders Folmer <php-internals_nospam@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

« previous php.internals (#122486) next »