Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125276
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 26 Aug 2024 11:59:53 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <a6d8a65c-7fd1-4246-bb14-b50fe3645bb1@app.fastmail.com>
In-Reply-To: 
 <CAJmjfvXkZsWUK3aGY+EM+3T52ezbdttJ2FSCoxh9t=wyHZCgMw@mail.gmail.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
 <3e0d031e-256f-47cd-9a2b-dcdc760f5498@scriptfusion.com>
 <e2cd7203-8a25-494d-9c9d-b8abad02c8e8@rwec.co.uk>
 <6afeb23a-867f-457d-9b13-fdf5af02c31e@scriptfusion.com>
 <F374AE89-A6E4-4C40-9C33-6569D47589ED@rwec.co.uk>
 <928d6c8c-c969-4d55-82ff-5da8fc3d3035@scriptfusion.com>
 <73301950-03e7-4f3c-9fab-402645f77272@gmx.de>
 <e2b64837-2a28-4968-bce3-bbc06165d2bd@scriptfusion.com>
 <bcfa8d1f-8a2f-4c39-bf5d-a85f0ba4e20e@app.fastmail.com>
 <CAJmjfvXkZsWUK3aGY+EM+3T52ezbdttJ2FSCoxh9t=wyHZCgMw@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Default expression
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Aug 26, 2024, at 6:36 AM, Jakob Givoni wrote:
> On Mon, Aug 26, 2024 at 12:49=E2=80=AFPM Rowan Tommins [IMSoP]=20
> <imsop.php@rwec.co.uk> wrote:
>> On Mon, 26 Aug 2024, at 10:14, Bilge wrote:
>> > You're absolutely right, I would be interested to see any viable pa=
tch=20
>> > that effectively implements a set of restrictions on how `default` =
may=20
>> > be used. Requesting it be done at the parser level was not meant as=
 a=20
>> > gotcha, that's just how I (with my lack of experience) would have=20
>> > approached it, but certainly trapping cases in the compiler is equa=
lly,=20
>> > if not more valid and/or practical.
>>=20
>> Another approach that occurred to me was in the executor: rather than=
 evaluating to the default value immediately, "default" could resolve to=
 a special value, essentially wrapping the reflection parameter info. Th=
en when the function is actually called, it would be "unboxed" and the a=
ctual value fetched, but use in any other context would be a type error.
>>=20
>> That would allow arbitrarily complex expressions to resolve to "defau=
lt", but not perform any operations on it - a bit like propagating sqrt(=
-1) through an engineering formula where you know it will be cancelled o=
ut eventually.
>>=20
>
> I 100% agree with this.
> "default" should not evaluate to a value before sending it as an=20
> argument to the function or method.
> I understand from what the RFC author wrote a while ago that doing so=20
> (evaluating to the actual default value using reflection) was the=20
> easier and perhaps only viable way at the moment, but if that's the=20
> case, I don't think the value of this RFC justifies doing something=20
> like that, which to me seems like a hack.
>
> For those already expressing interest in being able to modify a binary=20
> flag default parameter using this "trick", I still don't think it=20
> justifies this RFC. In my opinion, functions that accept multiple=20
> arbitrary options by compressing them into a binary flag have a badly=20
> designed interface to begin with.
>
> So, my 10c: Make "default" a pure keyword / immutable value if=20
> possible, or reconsider whether this feature is really worth the fuss.

The problem here is that `foo(default | ADDITIONAL_FLAG)` is so far the =
most compelling use case I've seen for this feature.  It's really one of=
 only two I see myself possibly using, frankly.  So a limitation that wo=
uld disallow that pattern would render the RFC almost useless.

The other compelling case would be the rare occasions where today you'd =
do something like this:

if ($user_provided_value) {
  foo($beep, $user_provided_value);
} else {
  foo($beep);
}

Which this RFC would allow to be collapsed into=20

foo($beep, $user_provided_value ?: default);

So far those are the two use cases I can realistically see being helpful=
, and I acknowledge both are.  I recognize that "limiting the allowed ex=
pression structures arbitrarily is way harder than it sounds" is a valid=
 argument as well.  At the same time, John C has offered some valid exam=
ples of cases where it would open up additional footguns, and we want to=
 minimize those in general.  Those shouldn't be ignored, either.

At the moment I'm on the fence on this RFC.  I could go either way right=
 now, so I'm watching to see how it develops.

--Larry Garfield