On Tue, May 28, 2024 at 2:10 PM Gina P. Banyard <intern...@gpb.moe> wrote: > > On Monday, 27 May 2024 at 02:31, Ilija Tovilo <tovilo.il...@gmail.com> wrote: > > > > On Wednesday, 8 May 2024 at 14:40, Gina P. Banyard intern...@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 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.
Mostly because I think handling exit and die as constants is misleading. exit; isn't a constant any more than yield; is. Instead, you could turn exit; into the same AST as exit(); (i.e. a function call), which will make the compiler handle it automatically. If you wish, I can have a quick look. > > 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. That would be great! I agree that this can be done in retrospect. Ilija
