I mean it’s easier than named parameters. I guess I replied to wrong thread, but wanted to contrast “default” with JSON_DEFAULT_DEPTH. Accepting string in integer parameter just creates mores issues. And please don’t use name conflicts as argument for not adding something. It’s absurd to stop adding anything in minor releases because name can conflict with userland, especially in case name is prefixed like here.
> On 7. Apr 2019, at 11:31, Craig Duncan <p...@duncanc.co.uk> wrote: > > Hi Gabriel, do you mean a constant for every parameter's default value? I'm > not sure how that's easier, and it's technically worse for BC as *default* is > already a keyword but your new global constants could clash with userland > ones. > > > > On Sun, 7 Apr 2019, 07:33 Gabriel O, <gade...@gmail.com > <mailto:gade...@gmail.com>> wrote: > Wouldn't better (and still easy and bc) solution be to just have constant > holding default value? > > On 6 April 2019 11:16:02 PM Craig Duncan <p...@duncanc.co.uk > <mailto:p...@duncanc.co.uk>> wrote: > > > Hi all, > > > > After starting to use https://wiki.php.net/rfc/json_throw_on_error > > <https://wiki.php.net/rfc/json_throw_on_error> in PHP > > 7.3 I've encountered the annoying issue of having to pass the $depth > > parameter as 512 every time I want json_decode() to throw. > > > > After doing this a few times I remembered the parameter skipping RFC that > > Stas proposed a few years ago: https://wiki.php.net/rfc/skipparams > > <https://wiki.php.net/rfc/skipparams> > > > > I've re-read the previous discussion and it seems to me there were two > > common arguments against: > > * Just design better APIs > > * Named parameters would be better > > > > Nobody has been able to crack named parameters (and it doesn't seem likely > > anytime soon), and as we've seen from the JSON example above it's not > > always as simple as having better APIs, so I wanted to see whether people > > would be willing to support the *default* keyword for optional parameters > > now. > > > > Thanks, > > Craig > > >
