On Sun, Aug 25, 2024, at 12:01, Bilge wrote: > On 25/08/2024 10:49, Juliette Reinders Folmer wrote: > > (resending as I accidentally originally send a private reply instead > > of sending the below to the list) > > > > On 24-8-2024 18:49, 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 > >> > > > > Hi Bilge, > Hi :) > > I like the idea, but see some potential for issues with ambiguity, > > which I don't see mentioned in the RFC as "solved". > > > > Example 1: > > ```php > > function foo($paramA, $default = false) {} > > foo( default: default ); // <= Will this be handled correctly ? > > ``` > > No, but not because of my RFC, but because $paramA is a required > parameter that was not specified. Assuming that was just a typo, the > following works as expected: > > function foo($paramA = 1, $default = false) { > var_dump($default); > } > foo(default: default); // bool(false) > > > Example 2: > > ```php > > callme( > > match($a) { > > 10 => $a * 10, > > 20 => $a * 20, > > default => $a * default, // <= Based on a test in the PR this > > should work. Could you confirm ? > > } > > ); > > ``` > Yes. > > Example 3: > > ```php > > switch($a) { > > case 'foo': > > return callMe($a, default); // I presume this shouldn't be a > > problem, but might still be good to have a test for this ? > > default: > > return callMe(10, default); // I presume this shouldn't be a > > problem, but might still be good to have a test for this ? > > } > > ``` > Yes. > > On that note, might it be an idea to introduce a separate token for > > the `default` keyword when used as a default expression in a function > > call to reduce ambiguity ? > Considering the Bison grammar compiles, I believe there can be no > ambiguity. I specifically picked `default` because I think it is the > most intuitive keyword to use for this, and it's conveniently already a > reserved word.
Other tools parse the tokens directly (for example, I have a tool to take php classes and convert them to graphql specifications. It parses the tokens emitted the tokenization extension), and having "default" tokens in unexpected places presents an ambiguity and BC break for those tools. By having a token (DEFAULT_PARAM_VALUE) or something to disambiguate might be better. I had assumed it was a separate token when I first read it, so this is a good point. — Rob
