Re: [PHP-DEV] Resurrecting named parameters

Hi! > 2. Throw a notice if a parameter name is changed. While LSP violations are > normally fatal errors (in PHP 8), we could use a lower-severity diagnostic > for this case, that allows code to still run, but makes developers aware of > the problem. (It should be noted that automatic fixup of

Re: [PHP-DEV] [RFC] Constructor Property Promotion

On Wed, Apr 8, 2020 at 1:56 PM Nicolas Grekas wrote: > > I would like to submit the following RFC for your consideration: >> https://wiki.php.net/rfc/constructor_promotion >> > > I love it :) > > Just one question: > Shouldn't default values be copied on the signature? That would be > expected

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

On Wed, Apr 8, 2020 at 9:37 AM Derick Rethans wrote: > > It's different. Changing from long to short array syntax makes it > unparsable by older versions of PHP. > All versions of PHP which don't support short array syntax have long been EOL for nearly 5 years now. We can't possibly be expected

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

On Wed, Apr 8, 2020 at 3:12 PM Sherif Ramadan wrote: > > So to recap on what's been discussed so far, because I plan to bring this > to a vote next week... > > I am updating the RFC to reflect that the change will no longer break > backwards compatibility. I will be adding an flags argument with

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

> On Apr 8, 2020, at 08:37, Derick Rethans wrote: > > I still believe that none of these options are needed. var_export() has > been added to generate PHP parser readable code. I think it was said earlier, but I'll say it again: having it generate parser-readable code is great, but having

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

On Wed, 8 Apr 2020, Sherif Ramadan wrote: > On Wed, Apr 8, 2020 at 9:22 AM Benjamin Morel > wrote: > > > > VAR_EXPORT_NO_INDEX > > > > Note that I wouldn't consider a BC break to change var_export()'s > > behaviour to always discard indexes when they're numeric, I'm not > > sure this should

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

On Wed, Apr 8, 2020 at 9:22 AM Benjamin Morel wrote: > > VAR_EXPORT_NO_INDEX > > Note that I wouldn't consider a BC break to change var_export()'s > behaviour to always discard indexes when they're numeric, I'm not sure this > should even be an option! > > Well, it might if people are testing

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

> VAR_EXPORT_NO_INDEX Note that I wouldn't consider a BC break to change var_export()'s behaviour to always discard indexes when they're numeric, I'm not sure this should even be an option! - Ben

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

So to recap on what's been discussed so far, because I plan to bring this to a vote next week... I am updating the RFC to reflect that the change will no longer break backwards compatibility. I will be adding an flags argument with the following 3 optional bitwise flags for var_export: -

[PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)

Hi all, First, the voters-in-favor will be pleased to find that I have released the request extension (v2) via PECL at . Second, I will be contacting the documentation team under separate cover to begin getting the ext/request documentation into the php.net

Re: [PHP-DEV] [RFC] Constructor Property Promotion

> I would like to submit the following RFC for your consideration: > https://wiki.php.net/rfc/constructor_promotion > I love it :) Just one question: Shouldn't default values be copied on the signature? That would be expected for me. (and that would make the properties still initialized when

Re: [PHP-DEV] [RFC] [DISCUSSION] Type casting in array destructuring expressions

Am 07.04.2020 um 19:24 schrieb Claude Pache: Le 7 avr. 2020 à 17:09, Enno Woortmann a écrit : As the proposal explicitly aims at type casts when working with data from a untyped source (eg. iterating over a CSV file, XML without a XSD defining the types of the elements) I feel that the

Re: [PHP-DEV] Resurrecting named parameters

Le mardi 7 avril 2020, 14:44:38 CEST Nikita Popov a écrit : > The larger problem is that internal functions don't have a well-defined > concept of parameter default value. Parameter defaults are implicit in C > code, and sometimes based on argument count checks. When named parameters > are