Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125236
Content-Type: text/plain;
	charset=us-ascii
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
Subject: Re: [PHP-DEV] [RFC] Default expression
In-Reply-To: <a99e6d57-2c3a-4344-8c42-3f8fdba7ff5f@rwec.co.uk>
Date: Sun, 25 Aug 2024 16:29:45 -0400
Cc: internals@lists.php.net
Content-Transfer-Encoding: quoted-printable
Message-ID: <9F07D1D1-E539-4F23-94F2-8957C2AE7A5E@zort.net>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <bf9b4a5b-108c-4092-8751-569c1374b054@rwec.co.uk>
 <F773FEAA-0717-43ED-A6D5-98C348298DD7@zort.net>
 <a99e6d57-2c3a-4344-8c42-3f8fdba7ff5f@rwec.co.uk>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: jbafford@zort.net (John Bafford)

On Aug 25, 2024, at 14:46, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> =
wrote:
>=20
> On 25/08/2024 18:44, John Bafford wrote:
>=20
>> Although I'm not sold on the idea of using default as part of an=20
>> expression, I would argue that a default function parameter value is=20=

>> fair game to be read and manipulated by callers. If the default value=20=

>> was intended to be private, it shouldn't be in the function =
declaration.
>=20
> There's an easy argument against this interpretation: child classes =
can freely change the default value for a parameter, as long as they do =
not make it mandatory. https://3v4l.org/SEsRm
> That matches my intuition: that the public API, as a contract, states =
that the parameter is optional; the specification of what happens when =
it is not provided is an implementation detail.
> For comparison, consider constructor property promotion; the caller =
shouldn't know or care whether a class is defined as:
> public function __construct(private int $bar) {}
> or:
> private int $my_bar;
> public function __construct(int $bar) { $this->my_bar =3D $bar; }
> The syntax sits in the function signature because it's convenient, not =
because it's part of the API.

This is only by current convention. It used to be that parameter names =
were not part of the API contract, but now with named parameters, they =
are. There's no reason default values couldn't (or shouldn't) become =
part of the API contract in the same way.

(Note that in some other languages, default parameter values are not =
only part of the API contract, but they're emitted into the clients when =
compiled, so an API can change/add/remove its default values and the =
client continues to function as it used to with the value as defined at =
compile time. This doesn't currently matter for PHP, where you have the =
full source to anything you run, but could become important later if PHP =
gained ahead-of-time compiled binary modules.)


>> One important case where reading the default value could be important =
is
>> in interoperability with different library versions. For example, a=20=

>> library might change a default parameter value between versions. If=20=

>> you're using the library, and want to support both versions, you =
might=20
>> both not want to set the value, and yet also care what the default =
value
>> is from the standpoint of knowing what to expect out of the function.
>=20
> This seems contradictory to me. If you use the default, you're telling =
the library that you don't care about that parameter, and trust it to =
provide a default.
> If you want to know what the library did with its arguments, =
reflecting the signature will never be enough anyway. For example, it's =
quite common to write code like this:
> function foo(?SomethingInterface $blah =3D null) {
>     if ( $blah =3D=3D=3D null ) {
>         $blah =3D self::_setup_default_blah();
>     }
>     // ...
> }
> A caller can't tell by looking at the signature that a new version of =
the library has changed what _setup_default_blah() returns. If the =
library doesn't provide an API to get $blah out later, then it's a =
private detail that the caller has no business inspecting.

Well, but that's the private default example I described. In that case =
you're not intended to be able to reason about what the default is, =
because it's a private implementation detail of the function, as opposed =
to being expressed in the parameter list. Although, if it weren't =
intended to be an implementation detail, the only thing stopping you =
from writing in the parameter list like this:

	function foo(SomethingInterface $blah =3D =
self::_setup_default_blah()) {...}

is because PHP doesn't currently allow default values to be computed at =
runtime. (Maybe it should.)

-John