> > The problem I see with this approach is that a keyword for skipping
> > parameters would really just be a stopgap solution until something
> > like Named Parameters can be added.
> >
> > Is it really appropriate to add a feature that only serves a temporary
> > purpose?
>
> That was an argu
Hi!
> The problem I see with this approach is that a keyword for skipping
> parameters
> would really just be a stopgap solution until something like Named
> Parameters
> can be added.
>
> Is it really appropriate to add a feature that only serves a temporary
> purpose?
That was an argument in 2
Why not just wrap the function in another function?
On Sat, 6 Apr 2019 at 23:46, Morgan Breden wrote:
>
> The problem I see with this approach is that a keyword for skipping
> parameters
> would really just be a stopgap solution until something like Named
> Parameters
> can be added.
>
> Is it re
The problem I see with this approach is that a keyword for skipping
parameters
would really just be a stopgap solution until something like Named
Parameters
can be added.
Is it really appropriate to add a feature that only serves a temporary
purpose?
On Sat, Apr 6, 2019 at 5:15 PM Craig Duncan w
Hi all,
After starting to use 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
Hello internals,
David and I would like to open the discussion on our joint RFC:
https://wiki.php.net/rfc/nullable-casting
Mainly, it would enable to use e.g. `(?int)$x` besides `(int)$x`.
We are looking forward to your feedback and, if possible, help to fill
in the "RFC Impact" subsections (ho
