On Monday, 27 May 2024 at 02:31, Ilija Tovilo <tovilo.il...@gmail.com> wrote:

> Hi Gina
> 
> On Sun, May 26, 2024 at 11:47 PM Gina P. Banyard intern...@gpb.moe 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 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

Reply via email to