2022年3月10日(木) 3:57 Tim Düsterhus :
> Hi
>
> On 3/9/22 11:48, Go Kudo wrote:
> > Proposed RFCs and implementations have been reorganized. The main changes
> > are as follows
> >
> > https://wiki.php.net/rfc/rng_extension
> > https://github.com/php/php-src/pull/8094
> >
>
> I've compared the RFC aga
2022年3月10日(木) 3:07 Larry Garfield :
> On Wed, Mar 9, 2022, at 4:48 AM, Go Kudo wrote:
> > Hello internals.
> >
> > Proposed RFCs and implementations have been reorganized. The main changes
> > are as follows
> >
> > https://wiki.php.net/rfc/rng_extension
> > https://github.com/php/php-src/pull/809
Hi everyone
It's been a while. Hope you are doing well.
Last year I sent an e-mail to the mailing about the current state of
string interpolation in PHP. I have now created an RFC to better
explain the current behavior and why it would make sense to
deprecate/remove some of it.
https://wiki.php.
On 11/03/2022 17:13, Ilija Tovilo wrote:
https://wiki.php.net/rfc/deprecate_dollar_brace_string_interpolation
Hi Ilija,
Thanks for progressing with this, and making a clear case why these
syntaxes are confusing and redundant.
I presume the intent here is that the engine will generate an
E
This RFC is confusing two different things:
1. variables inside strings (options 1, 2, 3)
2. dynamic variables names (option 4)
The 4th one is very useful.
$v = ${'param_' . $name};
There is no other practical way to do that, so removing that feature
would mean breaking something useful with no
