On Sun, Aug 25, 2024, at 15:35, Larry Garfield wrote:
> 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
> > think some of you might enjoy this one. Hit me with any feedback.
> >
> > This one already comes complete with working implementation that I've
> > been cooking for a little while. Considering I don't know C or PHP
> > internals, one might think implementing this feature would be
> > prohibitively difficult, but considering the amount of help and guidance
> > I received from Ilija, Bob and others, it would be truer to say it would
> > 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 previous 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 default here" in potential function calls, and the ones it
> doesn't, you call out explicitly as the justification for this RFC.
>
> The approach here seems reasonable overall. The mental model I have from 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 where they may." Is that about accurate?
>
> My main holdup is the need. I... can't recall ever having a situation where this is
> something I needed. Some of the examples show valid use cases (eg, the "default plus this
> binary flag" example), but again, I've never actually run into that myself in practice.
Potentially the most useful place would be in attributes. Take crell\serde (:p) for instance:
#[SequenceField(implodeOn: default . ' ', joinOn: ' ' . default . '
')]
Where you may just want it to be a little more readable, but aren't interested in the default
implosion. In attributes, it has to be a static expression and I think this passes that test? At
least that is one place I would find most useful.
Then there are things like the example I gave before, where you need to call some library code as
library code and pass through the intentions. It also gets us one step closer to something like
these shenanigans:
function configureSerializer(Serde $serializer = new SerdeCommon(formatters: default as
$formatters));
Where we can call configureSerializer(formatters: new JsonStreamFormatter()).
Some pretty interesting stuff.
>
> My other concern is the list of supported expression types. I understand how the
> implementation would naturally make all of those syntactically valid, but it seems many of them, if
> not most, are semantically nonsensical. Eg, default > 1 would take a presumably
> numeric default value and output a boolean, which should really never be type compatible with the
> 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 majority 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 something useful.
I'm reasonably certain you can write nonsensical PHP without this feature. I don't think
we should be the nanny of developers.
— Rob