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

On Saturday, 11 May 2024 at 09:05, Juliette Reinders Folmer <php-internals_nospam@adviesenzo.nl> wrote: > On 8-5-2024 15:40, Gina P. Banyard 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 >> There have been some slight tweaks to the implementation, namely that the transformation >> from a "constant" to a function is done at compile time and we do not hook into the >> behaviour of constants any longer. > > No objections from my side, though, yes, PHPCS will need to be updated/adjusted to work around > this, but that's no biggie. > > When reading the RFC, there are two things about which I still have questions. > > 1. As things are, exit and die > cannot be used as a label for a goto statement. > > ```php > goto exit; > > exit: > echo 'exited'; > ``` > https://3v4l.org/fluuk and > https://3v4l.org/cNMEW > > Will that change now exit would no longer be a reserved keyword > ? I had not thought about goto labels, but indeed it would be possible to use exit and die as goto labels with this RFC. I have clarrified this change in the RFC text and added tests for this in the PR. > 2. The RFC mentions the "old" semantics regarding type juggling for exit/die - always > cast to string - and it mentions that passing resources or arrays in the new situation will become a > TypeError, but that still leaves some room for interpretation for the other types, in particular the > handling of booleans. > > How I read the RFC, the type juggling would change as follows (but I may well be wrong!): > > | Param passed | Old | New | Consequences | > > |-----------------------|---------|-----------|---------------------------------------------------------------------------------------------------------------| > | integer | integer | integer | No change, interpreted as exit code | > | string | string | string | No change, interpreted as status message | > | bool | string | integer | Was status message, now exit code | > | float | string | integer | Was status message, now exit code, "Implicit conversion from > float to int loses precision" deprecation notice | > | null | string | integer | Was status message, now exit code, "Passing null to parameter > #1 ($status) of type string\|int is deprecated" | > | stringable object | string | string | No change, interpreted as status message | > | non-stringable object | string | TypeError | | > | array | string | TypeError | | > | resource | string | TypeError | | > > Might it be an idea to make all the type juggling changes explicit in the RFC ? (and correct > whatever I interpreted incorrectly) I have done so, and fixed the one case you got wrong. Best regards, Gina P. Banyard