Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
Hello internals, I updated the RFC to encompass all the feedback: https://wiki.php.net/rfc/deprecate-implicitly-nullable-types Let me know if there are any final remarks before we start the vote sometime next week. Best regards, Gina P. Banyard
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
Hi Nicolas, Thanks for your input and proactive measures! I've just finished the analysis you asked for: - code: https://gist.github.com/kocsismate/c0d10c820606dfe297f09374aa634df5 - results: https://gist.github.com/kocsismate/cf3bdfbf35eb10224ee5ecd29b39656b TLDR: there are 880 packages out of 2000 which use implicit nullable parameter types. We will mention this fact in the RFC soon, as well as the need for additionally taking care of non-optional arguments with default values. Regards, Máté
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
Hi Gina, Máté 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 > Thanks for the RFC. I have the same concerns as Larry but I don't have any ideas on how to make the migration more seamless, so personally I'm fine with deprecating in 8.4 and dropping in 9.0. For the record, Symfony was using the reverse rule (removing the nullable flag when the default was null already). This was done to reduce the overall visual debt™, but the arguments in favor of your proposal are sound. I ran php-cs-fixer on the codebase, you can see the patch here: https://github.com/symfony/symfony/pull/53612 TL;DR, this is a +/- 2000 lines change that's quite easy to do. I think the RFC is missing some impact analysis BTW, just to be sure voters can look at some data to make a best informed decision. There's one catch-22, which is that I had to manually fix non-optional arguments with default values (as a reminder, they're deprecated too): https://github.com/symfony/symfony/pull/53612/commits/fb9fa26102512090550f9137751f81677c06d5f9 Fixing them can be automated too but this is still a separate code transformation. I think this should be mentioned in the RFC. The impact on the ecosystem is going to be significant for sure, especially because of the previous CS of Symfony. But at least the transition has already started since we merged this in our oldest maintained version. Cheers, Nicolas
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
>
> 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.
Property types don't infer nullability from the default value being
null, so constructor properties don't allow it either. I'd say this is
not an inconsistency, but rather a *consistency* with what this RFC
proposes to deprecate and remove.
Highly supportive of this RFC :)
--
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-1-2024 10:50, 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 For what it's worth, I support this deprecation - one less "exception to the rule" to have to take into account and remember. As for the RFC: * While I don't think the impact will be that large and the fix is straight-forward, I believe it would still be good to include an impact analysis (top 2000 Packagist packages check) in the RFC to confirm this. * The RFC currently only talks about deprecating the syntax in PHP 8.4 and makes no mention of removing support for the syntax altogether in the future. Would it be an idea to include a proposal for removal of the syntax in the RFC ? * The RFC does not mention the impact of the function signature change on inheritance. I think it would be good to clarify that there is none. The changes will not cause an LSP violation in case of inheritance and can be made for parent/child classes independently of each other. Also see: https://3v4l.org/0qM7W * While the majority of projects will (hopefully) be able to use nullable types/union types with null to mitigate the deprecation, there are still projects which have a wide range of supported PHP versions with the minimum being below PHP 7.1 (yes, WordPress I'm looking at you). It might be worth mentioning in the "Backward incompatible changes" section what the options are for those projects to mitigate the deprecation. As far as I can see, that would come down to the following options: 1. [Best option] Raise the minimum supported PHP version to 7.1, use nullable types and remove the `null` default value. Including a code sample like the 3v4l I posted above should probably also help clarify the expected change to the code. 2. Removing the default value without making the type nullable. This would be a signature change and could cause problems if the parameter was previously optional, but that's for the project itself to make a judgment call on. 3. For scalar and array typed parameters, changing the default value to one which complies with the type. Again, this would be a signature change and in this case, it could cause problems if the parameter was previously required and not the last parameter before optional ones, but again, that's for the project itself to make a judgment call on. 4. Remove the type declaration + if the parameter is/was required, remove the default value. This would be a huge step backwards, but would still allow for making those signatures cross-version compatible. This again, would be a signature change and this would be one which would violate LSP in case of inheritance, but again, that's for the project itself to make a judgment call on. Hope I've captured all options, though not claiming completeness. Hope this helps. Smile, Juliette
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
FWIW I think one year is more than enough of deprecation time for any change, especially for something so easy as this. It's not like we are forcing users to upgrade to the newest version as soon as possible. I still haven't used PHP 8.3, and I most likely will not use it for another year. In practice, a year of deprecation time is much more for most of the people. Additionally, people can start fixing it right now. The tools already provide such an option and the alternative syntax has been in existence for some time. If we find out that the change is being more difficult to implement than anticipated, the solution would be to postpone the removal. Deprecation can happen in any version and I see no reason to restrict this by implementing a new policy. But if anyone would want to do this, then there should be a separate RFC and discussion for this. In terms of this RFC, I see no reason not to accept it. -- 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 Tuesday, 23 January 2024 at 16:37, Larry Garfield wrote: > On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote: > > > I fundamentally disagree with the logic that we somehow need to "plan" > > deprecations around how much time we need to provide users to upgrade. > > > I categorically disagree here. PHP has a terrible reputation, even among its > own boosters, for breaking people's stuff and making upgrades harder. That is > partially deserved, partially not. (I've written in defense of Internals' > improvements extensively.) But as a project we need to consider both the > practical and social impact of any breaking changes. PHP has a terrible reputation because it didn't try to fix any of its crap for years. PHP has a terrible reputation because it added random ill designed stuff at random prior to the RFC process. PHP has a terrible reputation because it has insane bonkers semantics. PHP has a terrible reputation because its image is stuck in 2005. PHP has a terrible reputation because of projects written in PHP having "bad" codebases. etc. etc. I've stopped counting how many times I've been sent "PHP: a fractal of bad design" [1], how many times have people have brought up to me the fact PHP is the only language they know that undeprecated something (for reference is_a() in 5.1), and other countless stuff that I need to hear semi often. Internals is blamed for making upgrades hard, the life of library maintainers hell, and everything that could be assigned blame to internals. But I have never seen internals tell userland to promote deprecations to exceptions, userland came up with this, and uses this as a tool to harass library maintainers. Maybe I'm just weird, but I don't actually care that projects still use PHP 7, 5, 4, or 3. Because there will always be such projects, and basing my decisions on those makes no sense to me. It helps that I also hear people that are satisfied and happy with the language being tighter, but those are rarely said publicly, because there is no need to complain online when one has nothing to complain about. And again, I frankly don't believe that providing 2, 3, 5, 10 years of deprecation before a removal is effectively different from providing 1 year. People will either fix it immediately, or leave it until the end of time and still make a fuss about it. > > You assert that this is 1-2 orders of magnitude less impactful than undefined > vars or null string params were. I have no data on that off hand either way, > so cannot confirm or deny that estimate. (If you do, that would be very > helpful. No sarcasm, it really would.) It is definitely more > tooling-handleable, and it sounds like there's ample existing tooling for it, > so that's great and will help, but as we've noted many times, people using > good tooling are the minority. I don't need data to know this change is less impactful. Undefined vars requires either tracking the source of the first usage, or guarding every usage with a null coalesce operator. Implicit coercions require the same thing, either tracking the source, guarding every usage, or doing the worst option to just chug an explicit cast in front. And both of these things can happen countless times all over the code base, thus flooding logs. Compared to this change, which requires changing the unique definition of the offending function/method signature. I cannot comprehend how at the same time we need to treat users as capable, intelligent, knowledge people when introducing features. And at the same time consider them to be incompetent, and lacking skills to use tooling. For this deprecation the tooling _already_ exists, if people don't want to use it, why? If people don't know about it, why? If people don't trust it, why? This is different from a bunch of other changes where any tooling would be brand new. > > There is indeed a related discussion around scheduling, deprecation timelines > in general, etc. As I said, I've tried to start that discussion in the past > and was mostly ignored. > > Maybe "all deprecations last for X releases, whatever the number" is a good > policy to have; I don't know. Deciding now that there will be an 8.5 and then > a 9.0 is also a viable option, which will also give 2 years grace period for > users to get up to speed on this change. That's the entire point of > deprecations. Maybe because fixed major release cycles for a programming language is just a bad idea? Because what does a "major" release entail for a programming language? And if someone wants to deprecate something in 8.5 what do we tell them? No? PHP is an open source project, people come and go, and start contributing at different times. And telling someone nah sorry you should have started contributing 3 years ago to be able to make this change is extremely toxic IMHO? (c.f. the debacle from last year) And when thinking of those sorts of policies, the health of the project and its
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Tue, Jan 23, 2024, at 2:18 AM, Gina P. Banyard wrote: > 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. ... I think you're grossly misreading my post. I reiterate: I *support* this change. I like it. I want it to happen. I am not proposing that we support broken old code indefinitely, nor have I ever done so. But, > I fundamentally disagree with the logic that we somehow need to "plan" > deprecations around how much time we need to provide users to upgrade. I categorically disagree here. PHP has a terrible reputation, even among its own boosters, for breaking people's stuff and making upgrades harder. That is partially deserved, partially not. (I've written in defense of Internals' improvements extensively.) But as a project we need to consider both the practical and social impact of any breaking changes. You assert that this is 1-2 orders of magnitude less impactful than undefined vars or null string params were. I have no data on that off hand either way, so cannot confirm or deny that estimate. (If you do, that would be very helpful. No sarcasm, it really would.) It is definitely more tooling-handleable, and it sounds
Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
On Tuesday, 23 January 2024 at 02:45, Juliette Reinders Folmer wrote: > 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. I had a hunch that PHP_CodeSniffer was able to handle this already, I just couldn't find the correct sniff. :) I'll mention it if/when I update the RFC text. 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 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] 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] [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.
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
