Re: [RFC] Transform exit() from a language construct into a standard function

On Monday, 27 May 2024 at 02:31, Ilija Tovilo <tovilo.ilija@gmail.com> wrote: > Hi Gina > > On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard internals@gpb.moe wrote: > > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard internals@gpb.moe wrote: > > > > > I would like to formally propose my idea for exit() as a function brought up to the > > > list on 2024-02-24 [1] with the following RFC: > > > https://wiki.php.net/rfc/exit-as-function > > > > As there haven't been any comments for nearly two weeks, I'm planning on opening > > the vote for the RFC on Tuesday. > > > As mentioned early on in private, I don't see a convincing reason to > remove tokenizer/parser support for exit/die. I'd rather see this > handled in the parser directly, by converting the standalone keywords > to function calls. This avoids any backwards incompatibility, and > avoids special handling in zend_compile_const. I must be honest, I don't really understand how parsers work, so I went with what I could understand and implement. But I'm struggling to see a reason for keeping the token in the first place, and what issues hooking into zend_compile_const() has. > > Another thing that's probably not too important: The PR likely breaks > dead code elimination for exit() and die(). This could be re-added by > checking for the never return type instead. Checking for a never return type seems more robust if it wasn't already supported by DCE. I will see if I can do this. > You'd also need to > special-case the lookup of exit/die in namespaced code, where it will > always refer to the global function (as they cannot be declared in > userland). This is a pre-existing issue with assert() too then, I am happy to fix this at the same time if the RFC passes. Best regards, Gina P. Banyard