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

On Monday, 27 May 2024 at 19:10, Claude Pache <claude.pache@gmail.com> wrote: > Hi Gina, > > It is ok, for exit to be wired to a function. However, the > paren-less exit syntax is absolutely reasonable and should be kept > in the long term (more on this below). It is true that your proposal doesn’t remove the paren-less > form, but the implementation (a hack around constant evaluation) strongly suggests that it is > desirable to deprecate it in the future (hey, it is even the very first item of the > Future scope section). Therefore, I think it is preferable to keep > proper parsing rules for exit. > > Now here is why I think that exit syntax without parentheses is > reasonable. For me, exit is a control-flow instruction, saying to > terminate the program, just like return terminates a function or > break terminates a loop. I don’t care about implementation > details, whether it is implemented as invoking a never-returning function, or as throwing a hidden > exception, or whatever. The fact is, in typical use: > > php header("Location: /somewhere/else.php"); exit; > > I would consider an oddity and useless noise to put empty parentheses after a bare > exit, just as I wouldn’t consider to put empty parentheses after a > bare return. > > (BTW... I wouldn’t describe a bare yield (equivalent to > yield null) as “constant” evaluation, even if it may be found in > same positions as a “real” constant.) > > —Claude Adding something to Future Scope does not mean I will pursue this, this is just a possible direction that can be done and needs to be argued on its own merits. And frankly I have no intension on pushing this, I would _rather_ remove support for passing strings to exit() than removing the paren-less form. It should be noted that in other programming languages, exit() is a function that requires an argument for the status code. So I don't think of it as a control-flow instruction (because I don't see terminating something as control flow) but if that's how you see it fine. If that's the only reason for keeping proper parsing rules, I'm not sure whether that's worthwhile IMHO. Best regards, Gina P. Banyard