Re: [RFC] Default expression

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