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

On Tuesday, 30 July 2024 at 13:47, Christoph M. Becker <cmbecker69@gmx.de> wrote: > Hi Gina! > > On 30.07.2024 at 11:49, Gina P. Banyard wrote: > > > 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. > > > As userland PHP developer, I always regarded exit as a control > flow > instruction (quite similar to break), and as such I'm not > really in > favor of converting it to a proper function (especially since it is not, > because the parantheses could be omitted). You are not the first person to mention this. I don't have any plans on doing anything else to exit, but I never really considered it to be a control flow instruction, but that is maybe just me. > > Would that RFC imply that I would need to write \\exit or have > a use exit clause to avoid dynamic namespace lookup? If so, I would > be even > less in favor of that change. No, since the new implementation where the token is preserved this is not needed. You cannot define the function in a namespace, nor disable it, nor use it as a goto label. The one benefit of having it become a proper function which can also be used as a statement is: - Using named arguments - Passing it to callable parameters - Usual type juggling semantics > > I do understand your point about the type juggling semantics, but I > might have addressed that differently. I almost always use exit > without argument (and if, only with an int), and die always > with a > string (and only for quick experiments), and I figure that this might be > what most contemporary code does (at least, I hope that the > do_something() or die() times have long gone). As such, having > exit > and die as alias could be changed, sticking with > exit as a control > flow instruction, and having die as proper function (which > could even > be implemented in userland), where exit would allow an optional int > argument (like break), and die() a required string argument. Of > course, this would be a much bigger BC break, but it seems to me the > cleaner solution. This might be a good idea in the long term to properly split exit and die and have them take only integers and string respectively, but I am not going to personally bother with this, even if I think this is a good idea. Best regards, Gina P. Banyard