Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123307
Subject: Re: [PHP-DEV] [RFC] Transform exit() from a language construct into a
 standard function
To: internals@lists.php.net
References: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe>
Message-ID: <663F26E3.3070408@adviesenzo.nl>
Date: Sat, 11 May 2024 10:05:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe>
Content-Type: multipart/alternative;
 boundary="------------020707080506090407020206"
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

This is a multi-part message in MIME format.
--------------020707080506090407020206
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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 ?

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)

Smile,
Juliette

--------------020707080506090407020206
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 8-5-2024 15:40, Gina P. Banyard
      wrote:<br>
    </div>
    <blockquote
cite="mid:GUMp_LJKefk4aLz9P9MA-zonKuik6uUNWZTtOAx-IeIhjPFsgfT3HHECPpyGF_ujq-LxI6tzBxMYgL5CMVGRkyzxSugweKix_YUGo2rXnb4=@gpb.moe"
      type="cite">
      <pre wrap="">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:
<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/exit-as-function">https://wiki.php.net/rfc/exit-as-function</a>

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.
</pre>
    </blockquote>
    <br>
    No objections from my side, though, yes, PHPCS will need to be
    updated/adjusted to work around this, but that's no biggie.<br>
    <br>
    When reading the RFC, there are two things about which I still have
    questions.<br>
    <br>
    1. As things are, `exit` and `die` cannot be used as a label for a
    goto statement.<br>
    <br>
    ```php<br>
    goto exit;<br>
    <br>
    exit:<br>
      echo 'exited';<br>
    ```<br>
    <a class="moz-txt-link-freetext" href="https://3v4l.org/fluuk">https://3v4l.org/fluuk</a>
    and <a class="moz-txt-link-freetext" href="https://3v4l.org/cNMEW">https://3v4l.org/cNMEW</a><br>
    <br>
    Will that change now `exit` would no longer be a reserved keyword ?<br>
    <br>
    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.<br>
    <br>
    How I read the RFC, the type juggling would change as follows (but I
    may well be wrong!):<br>
    <tt><br>
      | Param passed          | Old     | New       |
      Consequences                                                                                                 
      |</tt><tt><br>
    </tt><tt>|-----------------------|---------|-----------|---------------------------------------------------------------------------------------------------------------|</tt><tt><br>
    </tt><tt>| integer               | integer | integer   | No change,
      interpreted as exit
      code                                                                          
      |</tt><tt><br>
    </tt><tt>| string                | string  | string    | No change,
      interpreted as status
      message                                                                     
      |</tt><tt><br>
    </tt><tt>| bool                  | string  | integer   | Was status
      message, now exit
      code                                                                            
      |</tt><tt><br>
    </tt><tt>| float                 | string  | integer   | Was status
      message, now exit code, "Implicit conversion from float to int
      loses precision" deprecation notice |</tt><tt><br>
    </tt><tt>| null                  | string  | integer   | Was status
      message, now exit code, "Passing null to parameter #1 ($status) of
      type string\|int is deprecated" |</tt><tt><br>
    </tt><tt>| stringable object     | string  | string    | No change,
      interpreted as status
      message                                                                     
      |</tt><tt><br>
    </tt><tt>| non-stringable object | string  | TypeError
      |                                                                                                              
      |</tt><tt><br>
    </tt><tt>| array                 | string  | TypeError
      |                                                                                                              
      |</tt><tt><br>
    </tt><tt>| resource              | string  | TypeError
      |                                                                                                              
      |</tt><tt><br>
    </tt><br>
    Might it be an idea to make all the type juggling changes explicit
    in the RFC ? (and correct whatever I interpreted incorrectly)<br>
    <br>
    Smile,<br>
    Juliette
  </body>
</html>

--------------020707080506090407020206--