Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On 23-1-2024 3:18, Gina P. Banyard wrote: The RFC notes that PHPStan and friends have an easy flag to make the change, which is great, but still that's a minority of PHP devs that even know to use static analysis. One does not need to use a static analyser to determine or fix this issue, indeed, I didn't even mention static analysers in the RFC as PHP_CS_FIXER is a tool for enforcing coding styles and is capable of fixing this issue. This tool and other code formatting tools are used more widely and for longer than static analysers. While I concur that too few devs use the helpful tooling available to them, I can already tell you that PHPCompatibility for PHP_CodeSniffer will be able to detect and flag code subject to this deprecation without problems and I will make sure the sniff is available ahead of the PHP 8.4 release (providing the RFC passes). And the Slevomat Coding Standard for PHP_CodeSniffer already contains the `SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue` sniff to auto-fix non-nullable typed parameters with a `null` default value to be nullable typed as well, so it's not just CS-Fixer which can help with this. Smile, Juliette
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Monday, 22 January 2024 at 18:53, Larry Garfield wrote: > I am in support of this change. My only concern is timeline. This RFC would > deprecate it in 8.4, and presumably support would be removed in 9.0. While we > haven't discussed a timeline for 9.0, historically the pattern is every 5 > years, which would put 9.0 after 8.4, which means only one year of > deprecation notices for this change. There is no reason as to why 9.0 should come after 8.4, and I fundamentally disagree with the logic that we somehow need to "plan" deprecations around how much time we need to provide users to upgrade. To this day, I have never been provided any evidence that longer deprecation times actually lead to users upgrading their code sooner and not delay the inevitable. We were even told to shunt mass deprecation RFCs for 8.0 to 8.1, effectively reducing how much time users have to upgrade for the sake of simplifying the migration from 7.4 to 8.0. The idea for this RFC was floated around the time of PHP ***7***.4, but this was deemed too soon due to cross version compatibility. Moreover, asking core developers to magically figure out all the various ways PHP is bonkers or broken in a specific narrow time frame, just so userland can have X version where the deprecation exists until removal, is unreasonable. If this is the model that we should seek, then we should *completely* move away from our current versioning system and do something more like Python that provides 2 version where a feature is deprecated before removing support. E.g. features deprecated in Python 3.9 were removed in Python 3.11. As such, I will not entertain this idea of timelines and when it is the "right time" to deprecate something for it to be removed at the "right time". If this is something people feel strongly, an RFC to change what our versioning is and means should be done instead. > Given the massive amount of code that built up between 5.1 and 7.1, and 7.1 > and today, I worry that a year won't be enough time for legacy code to clean > up and it would be another "OMG you broke everything you evil Internals > !" like the "undefined is now warning" changes in 8.0. (In > both cases, well-written code any time from the past decade has no issue but > well-written code is seemingly the minority.) I find this comparison disingenuous, fixing undefined variables is one, if not two orders of magnitude harder than fixing this issue. Fixing implicit null to scalar types coercions for internal functions causes way more havoc than this for legacy codebases, and yet we have consistently maintained the rationale for the deprecation. While I do take into consideration the impact RFCs can have on existing code bases, I consider having clear, easy, and comprehensible semantics to be way more important than supporting some complicated and confusing semantics for the sake of BC. There will always be code running on a completely outdated version of PHP due to whatever reason. And refusing to fix the language and its semantics for the vast majority of new code that is going to be written in it feels like a bad decision to me. Especially if fixing it results in engine simplifications. We are our own project, and we need to make choices for the sake of the health of the project, and this means removing stuff in a reasonable timeline. I personally don't work on PHP to do legacy maintenance and keep running it at all cost, if I did want to do this I'd be writing COBOL. I work on PHP because I believe it has a long future ahead of itself, and that new people will learn it and use it. And forcing those people to need to learn, and remember bazillions of gotchas really doesn't sound fair to them IMHO. > The RFC notes that PHPStan and friends have an easy flag to make the change, > which is great, but still that's a minority of PHP devs that even know to use > static analysis. One does not need to use a static analyser to determine or fix this issue, indeed, I didn't even mention static analysers in the RFC as PHP_CS_FIXER is a tool for enforcing coding styles and is capable of fixing this issue. This tool and other code formatting tools are used more widely and for longer than static analysers. Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, Jan 22, 2024, at 9:11 PM, Matthew Weier O'Phinney wrote: > On Mon, Jan 22, 2024 at 12:54 PM Larry Garfield > wrote: > >> I am in support of this change. My only concern is timeline. This RFC >> would deprecate it in 8.4, and presumably support would be removed in 9.0. >> While we haven't discussed a timeline for 9.0, historically the pattern is >> every 5 years, which would put 9.0 after 8.4, which means only one year of >> deprecation notices for this change. >> > > This is... not true. There is literally no established pattern for when > major releases take place, either by length of time, or number of minor > releases. > > PHP 3 had no minor releases. PHP 4 had 4 minor releases before PHP 5 > dropped, and then a minor release happened AFTER PHP 5 was already in the > wild (4.4). PHP 5 had 7 minor releases, with MULTIPLE YEARS between some of > the minor releases before the current process was adopted towards the end > of its lifecycle. > > We are moving TOWARDS a fairly standard process, but there's no definite > plans for PHP 9 to follow after 8.4 as of yet, and the process does not > require it. I know there's no official statement regarding timeline. However, 5.3 (aka PHP 6) -> PHP 7 was 5 years. PHP 7 -> PHP 8 was 5 years. It's not unreasonable for folks to assume 9 comes 5 years after 8, whether that's the intention or not. Given the lengths of time involved there's not a great many data points to work from, but humans gonna pattern match. :-) In any case, my core point is a deprecation of this impact probably needs more than a year's lead time before it's actually removed. If we agree on that, we should plan around that and actually, you know, plan. >> Given the massive amount of code that built up between 5.1 and 7.1, and >> 7.1 and today, I worry that a year won't be enough time for legacy code to >> clean up and it would be another "OMG you broke everything you evil >> Internals !" like the "undefined is now warning" changes >> in 8.0. (In both cases, well-written code any time from the past decade >> has no issue but well-written code is seemingly the minority.) >> > > But I DO agree with the above. So this might be a time for us to start > discussing if/when we want a PHP 9 to occur. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, Jan 22, 2024 at 12:54 PM Larry Garfield wrote: > I am in support of this change. My only concern is timeline. This RFC > would deprecate it in 8.4, and presumably support would be removed in 9.0. > While we haven't discussed a timeline for 9.0, historically the pattern is > every 5 years, which would put 9.0 after 8.4, which means only one year of > deprecation notices for this change. > This is... not true. There is literally no established pattern for when major releases take place, either by length of time, or number of minor releases. PHP 3 had no minor releases. PHP 4 had 4 minor releases before PHP 5 dropped, and then a minor release happened AFTER PHP 5 was already in the wild (4.4). PHP 5 had 7 minor releases, with MULTIPLE YEARS between some of the minor releases before the current process was adopted towards the end of its lifecycle. We are moving TOWARDS a fairly standard process, but there's no definite plans for PHP 9 to follow after 8.4 as of yet, and the process does not require it. > > Given the massive amount of code that built up between 5.1 and 7.1, and > 7.1 and today, I worry that a year won't be enough time for legacy code to > clean up and it would be another "OMG you broke everything you evil > Internals !" like the "undefined is now warning" changes > in 8.0. (In both cases, well-written code any time from the past decade > has no issue but well-written code is seemingly the minority.) > But I DO agree with the above. So this might be a time for us to start discussing if/when we want a PHP 9 to occur. > > -- Matthew Weier O'Phinney mweierophin...@gmail.com https://mwop.net/ he/him
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, Jan 22, 2024, at 7:30 PM, Jorg Sowa wrote: >> The only solution I can think of is to keep the deprecation in place > until PHP 10, but that's a very long time from now and the RFC says this > simplifies a decent amount of engine code, so I'm not wild about that idea. > > Another solution is to have version 8.5. Also given the fact that much of > the deprecated code will be removed in PHP 9.0, maybe it's worth discussing > how long should be period between 9 and 10? > > Kind regards, > Jorg Sowa I've argued several times that the ecosystem would benefit greatly from having scheduled majors. It would make planning around deprecations vastly easier, for instance. So far, that's fallen on deaf ears. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
> The only solution I can think of is to keep the deprecation in place until PHP 10, but that's a very long time from now and the RFC says this simplifies a decent amount of engine code, so I'm not wild about that idea. Another solution is to have version 8.5. Also given the fact that much of the deprecated code will be removed in PHP 9.0, maybe it's worth discussing how long should be period between 9 and 10? Kind regards, Jorg Sowa
Re: [PHP-DEV] [RFC] Add http_(get|clear)_last_request_headers() function
On Mon, Jan 22, 2024, at 1:48 AM, Gina P. Banyard wrote: > Hello internals, > > I have updated the RFC to include a motivation and rejected ideas section: > https://wiki.php.net/rfc/http-last-response-headers > > Unless there is further discussion, I intend to open the vote for the > RFC on Wednesday the 24th of January. > > Best regards, > > Gina P. Banyard The change seems reasonable, but I am still nervous about removing anything without a deprecation. We need to be better about that for user-space. Per my previous message we *probably* are looking at one year from 8.4 to deprecation removal in 9.0; For a change this obscure I think that timeframe is acceptable, as its impact is much smaller. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, Jan 22, 2024, at 9:50 AM, Gina P. Banyard wrote: > Hello internals, > > Máté Kocsis and myself would like to propose deprecating implicitly > nullable parameter types. > > The RFC is available on the wiki at the following address: > https://wiki.php.net/rfc/deprecate-implicitly-nullable-types > > > Best regards, > > Gina P. Banyard I am in support of this change. My only concern is timeline. This RFC would deprecate it in 8.4, and presumably support would be removed in 9.0. While we haven't discussed a timeline for 9.0, historically the pattern is every 5 years, which would put 9.0 after 8.4, which means only one year of deprecation notices for this change. Given the massive amount of code that built up between 5.1 and 7.1, and 7.1 and today, I worry that a year won't be enough time for legacy code to clean up and it would be another "OMG you broke everything you evil Internals !" like the "undefined is now warning" changes in 8.0. (In both cases, well-written code any time from the past decade has no issue but well-written code is seemingly the minority.) The RFC notes that PHPStan and friends have an easy flag to make the change, which is great, but still that's a minority of PHP devs that even know to use static analysis. The only solution I can think of is to keep the deprecation in place until PHP 10, but that's a very long time from now and the RFC says this simplifies a decent amount of engine code, so I'm not wild about that idea. I am open to alternate suggestions for how we can make this transition more graceful. Again, fully support the change, I just want to make sure it's graceful. --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On 22 January 2024 10:21:12 GMT, tag Knife wrote: >As you are mistaking `iint $var = null` params as "nullable". Which they >are not, they are "optional default" parameters. The feature which is being discussed is that, for the specific case of "= null", the parameter is made both optional *and* nullable. To make it clearer, the following all declare default values within the allowed type: int $foo = 1 int|string $foo = 'hello' ?int $foo = 1 ?int $foo = null The following all lead to a type error, because the default value isn't allowed for the declared type: int $foo = 'hello' int|string $foo = new DateTime; ?int $foo = 'hello' However, there is a special case: for purely historical reasons, a default of null is allowed *even when it doesn't match the declared type*: int $foo = null int|string $foo = null These are processed as though they were declared as nullable types; and the fix for the proposed deprecation would be to do so: ?int $foo = null int|string|null $foo = null The fact that the feature is tricky to explain is a good reason to deprecate it, and I think I support the proposal unless I see a good argument against. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: Wiki Access request
Hi Carlos You should now have access to the /internals sub-pages. On Mon, Jan 22, 2024 at 11:38 AM Barel wrote: > > I didn't know that there was a list of tech resources listed in the > "CONTRIBUTING.md" file. I have been researching resources that have > information about PHP internals and have found a lot, more than twenty. I > can think of three possibilities: > - List them all in the contributing document but this can be a bit > overwhelming as, like I said, the number of resources available is big Feel free to share this list here, on GitHub or otherwise. I'm skeptical whether throwing partially outdated resources at people is actually helpful. > - Add a new page in the Github repo with all these links and link to that > page from the contributing page > - Keep the list in the wiki and link to that page from the contributing page One of the reasons I'd like to move off of the wiki for these things is that there is no review process. We highly value volunteer work, but trusting new contributors to blindly make changes to official guides is obviously somewhat problematic. I'd prefer to make CONTRIBUTING.md the "official list" for now. This file is allowed to be long. And as mentioned, I suspect that the list of 20+ items may be trimmed. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] [RFC] Collecting All Policies Into One Repository
On Fri, 5 Jan 2024, Derick Rethans wrote: > I have just opened the voting on the "Policy Repository" RFC. It will > run until January 22nd, 2024 at 08:00 UTC: > > https://wiki.php.net/rfc/policy-repository#voting_choices Voting is now closed, and the RFC was accepted unanimously, with 28 for and 0 against. I will add a link to all affected RFC's wiki pages, and other related pages, that the canonical version now lives in the new repository, at: https://github.com/php/policies cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, 22 Jan 2024 at 11:51, Gina P. Banyard wrote:
> Hello internals,
>
> Máté Kocsis and myself would like to propose deprecating implicitly
> nullable parameter types.
>
> The RFC is available on the wiki at the following address:
> https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
>
>
> Best regards,
>
> Gina P. Banyard
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
I just encountered this language inconsistency when trying to remove
nullable from a constructor-promoted property:
```
class MyClass
{
public function __construct(
public ?string $title = null // removing "?" here causes "Fatal
error: Cannot use null as default value"
) {
$this->title = $title ?: resolveTitle();
}
}
```
Which is fine, there's a simple workaround, it was just surprising.
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, Jan 22, 2024 at 11:21 AM tag Knife wrote: > On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard wrote: > > > Hello internals, > > > > Máté Kocsis and myself would like to propose deprecating implicitly > > nullable parameter types. > > > > The RFC is available on the wiki at the following address: > > https://wiki.php.net/rfc/deprecate-implicitly-nullable-types > > > > > > Best regards, > > > > Gina P. Banyard > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > Also just did a quick test, and i don't believe this would be possible. It > would remove functionality from the language widely used. > As you are mistaking `iint $var = null` params as "nullable". Which they > are not, they are "optional default" parameters. The equals > can be succeeded by any value, to set the parameter to such variable where > the parameter is not passed. `int ?$arg` is not provided as > an alternative, the directive `int ?$arg` simple allows the parameters to > be passed as null, it is still required to pass through the > parameter. > > To clarify > > `T ?$var` = Requires the parameter to be passed to the function, null > value allowed > `T $var = null` = Does not require the parameter to be passed to the > function, is set to null if not. > > https://3v4l.org/IWsqK Your example contains `int2` as type with a default value of `null`. This works because it implicitly marks the class `int2` as nullable. If you were to set this default value to `1` via `int2 $int2 = 1` it breaks with "Fatal error: Cannot use int as default value for parameter $int2 of type int2" Anyhow, `= null` implicitly makes the parameter nullable even if the type doesn't specify it's nullable. The argument is that if the type isn't nullable, then the default value may not be null either.
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
I fully support this. I even wanted to propose this RFC myself. Implicitly nullable parameters are extremely confusing in PHP 8 and they are very easy to replace.
[PHP-DEV] Re: Wiki Access request
> > > I can absolutely give you write access to these pages. Updating this > list to reflect more up-to-date resources certainly makes sense. > > As you probably know, there are a number of different places where php > internals are documented, and I think that, long-term, it makes sense > to try to consolidate these efforts. We briefly spoke about this in > the last foundation meeting. > > We have some documentation in the php-src repository itself, a > significant amount in the php internals book > (https://www.phpinternalsbook.com/), some in the wiki, some on blogs > of current or previous contributors, etc. There are a number of things > that are important when it comes to documentation, like convenience, > access, history, discoverability, etc. > > While not the worst, I don't think the wiki is the best place for this > work. Handling documentation directly through Git in PHPs main > repository (or at least a repository in the PHP organization) would > likely tick the most boxes. Providing documentation with PRs might > also improve the understanding of intention of the changes for > reviewers. > > As for links to other references, I believe the CONTRIBUTING.md file > is currently the most up-to-date. > > > https://github.com/php/php-src/blob/master/CONTRIBUTING.md#technical-resources > > Rather than duplicating this list on the wiki, it might make sense to > reference the CONTRIBUTING.md file, and extend it as necessary. > > Ilija > > Hi Ilija, I didn't know that there was a list of tech resources listed in the "CONTRIBUTING.md" file. I have been researching resources that have information about PHP internals and have found a lot, more than twenty. I can think of three possibilities: - List them all in the contributing document but this can be a bit overwhelming as, like I said, the number of resources available is big - Add a new page in the Github repo with all these links and link to that page from the contributing page - Keep the list in the wiki and link to that page from the contributing page Please let me know what you think would be the best way going forward. No matter what we do, we need to make sure that this info is collected in a single place and not duplicated. And no matter what we do, the wiki page needs to be cleaned so I'd be grateful if you could provide this access. Depending on what we decide to do, I will clean up the wiki and create a PR for the php-src repo with the related changes Cheers Carlos
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard wrote: > Hello internals, > > Máté Kocsis and myself would like to propose deprecating implicitly > nullable parameter types. > > The RFC is available on the wiki at the following address: > https://wiki.php.net/rfc/deprecate-implicitly-nullable-types > > > Best regards, > > Gina P. Banyard > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > Also just did a quick test, and i don't believe this would be possible. It would remove functionality from the language widely used. As you are mistaking `iint $var = null` params as "nullable". Which they are not, they are "optional default" parameters. The equals can be succeeded by any value, to set the parameter to such variable where the parameter is not passed. `int ?$arg` is not provided as an alternative, the directive `int ?$arg` simple allows the parameters to be passed as null, it is still required to pass through the parameter. To clarify `T ?$var` = Requires the parameter to be passed to the function, null value allowed `T $var = null` = Does not require the parameter to be passed to the function, is set to null if not. https://3v4l.org/IWsqK
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Mon, 22 Jan 2024 at 09:51, Gina P. Banyard wrote: > Hello internals, > > Máté Kocsis and myself would like to propose deprecating implicitly > nullable parameter types. > > The RFC is available on the wiki at the following address: > https://wiki.php.net/rfc/deprecate-implicitly-nullable-types > > > Best regards, > > Gina P. Banyard > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > >From a quick glance this looks like it would be very difficult to implement without completely redoing default optional parameters as a whole.
[PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
Hello internals, Máté Kocsis and myself would like to propose deprecating implicitly nullable parameter types. The RFC is available on the wiki at the following address: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types Best regards, Gina P. Banyard -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs
Hi everyone I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC. https://wiki.php.net/rfc/rfc1867-non-post Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Newly Created Wiki Account - Quick Introduction
Hi Jair! On Mon, Jan 22, 2024 at 5:14 AM Jair Humberto wrote: > > My name is Jair Humberto, I am brazilian and have been working with PHP > since 2006. I am super excited about the new things PHP has launched lately > and finally realised that I can contribute as well. I think this is a new > fase of my career, I want to learn a bit more about the php source code and > processes and I plan to start contributing with small things, but my first > main goal (long term) is to make possible generics in PHP, one day! Welcome! Note that you do not need a wiki account for contributing to PHP. Source code is managed on GitHub (https://github.com/php/php-src) and changes are made via pull requests. Nowadays, you'll only really need a wiki account to create RFCs. Check the CONTRIBUTING.md file for some good resources on the internals of PHP. https://github.com/php/php-src/blob/master/CONTRIBUTING.md#technical-resources If you need any guidance, feel free to contact me. Ilija -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
