Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124629
Content-Type: multipart/alternative;
 boundary="------------XX4qtaJlZRO3BkNvszerVY0G"
Message-ID: <ab9ded6e-05be-43e7-bafb-f8a81eeba7e9@scriptfusion.com>
Date: Fri, 26 Jul 2024 22:54:05 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: internals@lists.php.net
Content-Language: en-GB
Subject: [PHP-DEV] Explicit callee defaults
From: bilge@scriptfusion.com (Bilge)

This is a multi-part message in MIME format.
--------------XX4qtaJlZRO3BkNvszerVY0G
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Internals,

New RFC idea just dropped. When writing a function, we can specify 
defaults for its parameters, and when calling a function we can leverage 
those defaults /implicitly/ by not specifying those arguments or by 
"jumping over" some of them using named parameters. However, we cannot 
/explicitly/ use the defaults. But why would we want to?

Sometimes we want to effectively /inherit/ the defaults of a function 
we're essentially just proxying. One way to do that is copy and paste 
the entire method signature, but if the defaults of the proxied method 
change, we're now overriding them with our own, which is not what we 
wanted to do. It is possible, in a roundabout way, to avoid specifying 
the optional parameters by filtering them out (as shown in the next 
example). The final possibility is to use reflection and literally query 
the default value for each optional parameter, which is the most awkward 
and verbose way to inherit defaults.

Let's use a concrete example for clarity.

function query(string $sql, int $limit = PHP_INT_MAX, int $offset = 0);

function myQuery(string $sql, ?int $limit = null, ?int $offset = null) {
     query(...array_filter(func_get_args(), fn ($arg) => $arg !== null));
}

In this way we are able to filter out the null arguments to inherit the 
callee defaults, but this code is quite ugly. Moreover, it makes the 
(sometimes invalid) assumption that we're able to use `null` for all the 
optional arguments.

In my new proposal for /explicit /callee defaults, it would be possible 
to use the `default` keyword to expressly use the default value of the 
callee in that argument position. For example, the above implementation 
for myQuery() could be simplified to the following.

function myQuery(string $sql, ?int $limit = null, ?int $offset = null) {
     query($sql, $limit ?? default, $offset ?? default);
}

Furthermore, it would also be possible to "jump over" optional 
parameters /without/ using named parameters.

json_decode($json, true, default, JSON_THROW_ON_ERROR);

This proposal is built on the assumption that it is possible to specify 
that PHP should only accept the `default` expression in method and 
function call contexts. For example, it would not be valid to return 
`default` from a function and substitute it that way; my proposal is to 
only permit `default` in literal function calling contexts. My knowledge 
of internals is insufficient (read: non-existent) to know whether or not 
this restriction is possible to implement, but if it is, I think this is 
a good idea. What do you think?

Cheers,
Bilge

--------------XX4qtaJlZRO3BkNvszerVY0G
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hi Internals,</p>
    <p>New RFC idea just dropped. When writing a function, we can
      specify defaults for its parameters, and when calling a function
      we can leverage those defaults <i>implicitly</i> by not
      specifying those arguments or by "jumping over" some of them using
      named parameters. However, we cannot <i>explicitly</i> use the
      defaults. But why would we want to?</p>
    <p>Sometimes we want to effectively <i>inherit</i> the defaults of
      a function we're essentially just proxying. One way to do that is
      copy and paste the entire method signature, but if the defaults of
      the proxied method change, we're now overriding them with our own,
      which is not what we wanted to do. It is possible, in a roundabout
      way, to avoid specifying the optional parameters by filtering them
      out (as shown in the next example). The final possibility is to
      use reflection and literally query the default value for each
      optional parameter, which is the most awkward and verbose way to
      inherit defaults.</p>
    <p>Let's use a concrete example for clarity.</p>
    <p>function query(string $sql, int $limit = PHP_INT_MAX, int $offset
      = 0);</p>
    <p>function myQuery(string $sql, ?int $limit = null, ?int $offset =
      null) {<br>
          query(...array_filter(func_get_args(), fn ($arg) =&gt; $arg
      !== null));<br>
      }</p>
    <p>In this way we are able to filter out the null arguments to
      inherit the callee defaults, but this code is quite ugly.
      Moreover, it makes the (sometimes invalid) assumption that we're
      able to use `null` for all the optional arguments.</p>
    <p>In my new proposal for <i>explicit </i>callee defaults, it
      would be possible to use the `default` keyword to expressly use
      the default value of the callee in that argument position. For
      example, the above implementation for myQuery() could be
      simplified to the following.</p>
    <p>function myQuery(string $sql, ?int $limit = null, ?int $offset =
      null) {<br>
          query($sql, $limit ?? default, $offset ?? default);<br>
      }</p>
    <p>Furthermore, it would also be possible to "jump over" optional
      parameters <i>without</i> using named parameters.</p>
    <p>json_decode($json, true, default, JSON_THROW_ON_ERROR);</p>
    <p>This proposal is built on the assumption that it is possible to
      specify that PHP should only accept the `default` expression in
      method and function call contexts. For example, it would not be
      valid to return `default` from a function and substitute it that
      way; my proposal is to only permit `default` in literal function
      calling contexts. My knowledge of internals is insufficient (read:
      non-existent) to know whether or not this restriction is possible
      to implement, but if it is, I think this is a good idea. What do
      you think?</p>
    <p>Cheers,<br>
      Bilge<br>
    </p>
  </body>
</html>

--------------XX4qtaJlZRO3BkNvszerVY0G--