On Saturday, 11 May 2024 at 09:05, Juliette Reinders Folmer <php-internals_nos...@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
