Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125209
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sun, 25 Aug 2024 08:35:14 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <0cfd3a28-3cb0-4478-85fb-cf086d8e5c66@app.fastmail.com>
In-Reply-To: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.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 Sat, Aug 24, 2024, at 11:49 AM, Bilge wrote:
> Hi gang,
>
> New RFC just dropped: https://wiki.php.net/rfc/default_expression. I=20
> think some of you might enjoy this one. Hit me with any feedback.
>
> This one already comes complete with working implementation that I've=20
> been cooking for a little while. Considering I don't know C or PHP=20
> internals, one might think implementing this feature would be=20
> prohibitively difficult, but considering the amount of help and guidan=
ce=20
> I received from=C2=A0Ilija, Bob and others, it would be truer to say i=
t would=20
> have been more difficult to fail! Huge thanks to them.
>
> Cheers,
> Bilge

I am still not fully sold on this, but I like it a lot better than the p=
revious attempt at a default keyword.  It's good that you mention named =
arguments, as those do replace like 95% of the use cases for "put defaul=
t here" in potential function calls, and the ones it doesn't, you call o=
ut explicitly as the justification for this RFC.

The approach here seems reasonable overall.  The mental model I have fro=
m the RFC is "yoink the default value out of the function, drop it into =
this expression embedded in the function call, and let the chips fall wh=
ere they may."  Is that about accurate?

My main holdup is the need.  I... can't recall ever having a situation w=
here this is something I needed.  Some of the examples show valid use ca=
ses (eg, the "default plus this binary flag" example), but again, I've n=
ever actually run into that myself in practice.

My other concern is the list of supported expression types.  I understan=
d how the implementation would naturally make all of those syntactically=
 valid, but it seems many of them, if not most, are semantically nonsens=
ical.  Eg, `default > 1` would take a presumably numeric default value a=
nd output a boolean, which should really never be type compatible with t=
he function being called.  (A param type of int|bool is a code smell at =
best, and a fatal waiting to happen at worst.)  In practice, I think a m=
ajority of those expressions would be logically nonsensical, so I wonder=
 if it would be better to only allow a few reasonable ones and block the=
 others, to keep people from thinking nonsensical code would do somethin=
g useful.

--Larry Garfield