Am 06.08.2024, 09:43:21 schrieb Benjamin Außenhofer <kont...@beberlei.de>:
> > > Am 30.07.2024, 11:49:52 schrieb Gina P. Banyard <intern...@gpb.moe>: > >> Hello Internals, >> >> I have just opened the vote for the "Transform exit() from a language >> construct into a standard function" RFC: >> https://wiki.php.net/rfc/exit-as-function >> >> The vote will last for two weeks until the 13th of August 2024. >> >> Best regards, >> >> Gina P. Banyard >> > > Hi Gina, > > I was ambivalent to this before, but after reading the discussion, voted > no for two reasons: > > > - exit without parenthesis s still not a function, that does not makes > handling this on extension level (tools, profilers) more reliable, instead > more confusing. I don’t mind the work this might cause for an extension, so > i don’t join Christoph’s and Derick’s argument here that this a break for > extensions that disqualifies the change. > > Tim pointed out to me that my argument here is wrong, since exit; will be transformed to exit() at compile time, I did not read this from my first read-through of the RFC, but now I see it in the text. So this point does not hold anymore. > - If it still does not allow me to set exit as disabled_functions, > then this creates an inconsistency > > That left me wondering why disabled_functions does not work, and I see the PR adds a special case for both functions. So disabling them „could“ potentially work. > I also have a question: From a userland perspective, it looks it creates > inconsistency calling exit with global namespace prefix, depending on > parenthesis or? \exit(); will now work, but \exit; will not? > > Also if https://github.com/php/php-src/pull/4084 taught me anything, > trying to add eval support for disabled_functions, then maybe we should > throw warnings instead when using that ini setting to disable op codes, > instead of silently ignoring that this won’t work. >
