Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 23:03, Mark Randall wrote: On 23/02/2022 19:32, Rowan Tommins wrote I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. It is already part of the RFC within the "proposed PHP versions" section. It doesn't mention any particular wording, and says the change "may be included". I'm not sure what that means. If I vote "yes", am I writing a blank cheque for anyone to change the message to anything? More importantly, am I approving removal even if the warning message isn't changed? I'm not sure when else this decision would be made, other than as part of the RFC, so am suggesting the "may" be changed to "will", and a specific wording proposed. Or, if you think changing the message isn't necessary, "may" can be changed to "will not", and people can vote on that basis. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 24/02/2022 02:31, Bob Weinand wrote: However, should your RFC pass, it is not possible to say "hey, I generally consider this a low impact class of errors, please try to continue". This is correct. As the custodians of the language, it is our responsibility to decide what the engine considers low / high impact and act accordingly. In some cases users get the choice, but in most cases we make the choice for them. We have internals and the voting system precisely for this reason, to have a broad number of voices involved in those decisions. If users wish to use the latest versions, they must ensure they meet its requirements, this is really no different than any other BC break we do for the good of the language and its users. A couple of years ago we voted to promote 13 things to become errors / type errors, and I note you voted in favour of 12 of them, without requiring an opt-out. I must therefore assume you consider the use of undefined variables to be a legitimate coding style, and that's fine if that is your position. This RFC boils down to internals deciding, as a group, that it isn't one we want to support in future. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Hey Mark, For me, there's a fundamental shortcoming of this proposal: - You cannot opt out. Currently, as you describe in your RFC, it is perfectly possible, to opt into making this category of errors fail hard (throw an exception in an error handler). However, should your RFC pass, it is not possible to say "hey, I generally consider this a low impact class of errors, please try to continue". As such, given that PHP is meant to appeal to a broad class of use cases, I am strongly against this change as proposed. Bob > Am 18.02.2022 um 00:28 schrieb Mark Randall : > > Internals, > > Following on from my previous thread, I think we are now in a position where > we can begin formal discussions on an RFC to promote undefined variables to > Error exceptions in PHP 9.0. > > I present: > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > I still intend to bring other error promotions forward, potentially in > collaboration with other developers, but as this is the biggest change, and > the most likely to attract a large number of comments, I thought it deserving > of a standalone RFC. > > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 19:32, Rowan Tommins wrote I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. It is already part of the RFC within the "proposed PHP versions" section. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 18:42, Mark Randall wrote: It may be that in 8.2 if this RFC passes that message will change to include "This will throw an error in PHP 9" I think that wording change should be part of the proposed change in the RFC. Otherwise, a lot of people simply won't know the decision to remove it has been made and will be surprised when 9.0 comes around. I used a similar approach in https://wiki.php.net/rfc/deprecate-bareword-strings because I wanted the visibility of E_WARNING but the clear mention of deprecation. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23/02/2022 18:02, Nicolas Grekas wrote: I mean in addition yes, deprecation before warning. I don't see this happening. An engine warning is as stark a mechanism as we have available that you either made a mistake, or shouldn't be doing something, without preventing you from actually doing it. It may be that in 8.2 if this RFC passes that message will change to include "This will throw an error in PHP 9", but giving multiple messages for it is not beneficial IMO. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Yeah, please don't: yet another side effect, deep in some `vendor` cruft. Just stop it, please: I almost have PTSD from 8.1. On Wed, 23 Feb 2022, 19:02 Nicolas Grekas, wrote: > Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a > écrit : > > > On 23.02.2022 at 16:29, Nicolas Grekas wrote: > > > > > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a > > écrit : > > > > > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < > > >> nicolas.grekas+...@gmail.com> wrote: > > >> > > >>> But this makes me think: we should trigger a deprecation just before > > all > > >>> corresponding warnings! > > >> > > >> Please, no more deprecation warnings, make it stop > > >> Yes, undefined variables are a problem, but I just spent 6 months in > > >> `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but > > >> frustration: this stuff is statically introspectible, and even more > > >> side-effects are just more trouble. > > > > > > I'm not going to be affected by this RFC at all, and neither are you, > > since > > > we use throwing error handlers. But ppl that do rely on code bases that > > > have undefined vars "by design" will be. I would bet that the number of > > ppl > > > in that affected group and that also use a static analyser is very very > > > small. This means that static analysers are not a pragmatic solution > > here. > > > > That. > > > > > Ppl that don't use static analysers deserve a prior notice. There is a > > > dedicated reporting mechanism in place and we should use it IMHO. With > > new > > > deprecations added to PHP 8.1, the ecosystem realized that the tooling > > > needed to improve - and it did (phpunit, Laravel, etc.). We can and > > should > > > add new runtime deprecations when planning a BC break. > > > > > > Please consider adding this deprecation Mark (and others.) > > > > Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I > > wouldn't be happy either way. > > > > I mean in addition yes, deprecation before warning. > > I considered grouping them as E_DEPRECATED|E_WARNING but that'd break many > userland error handlers I fear. >
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a écrit : > On 23.02.2022 at 16:29, Nicolas Grekas wrote: > > > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a > écrit : > > > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < > >> nicolas.grekas+...@gmail.com> wrote: > >> > >>> But this makes me think: we should trigger a deprecation just before > all > >>> corresponding warnings! > >> > >> Please, no more deprecation warnings, make it stop > >> Yes, undefined variables are a problem, but I just spent 6 months in > >> `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but > >> frustration: this stuff is statically introspectible, and even more > >> side-effects are just more trouble. > > > > I'm not going to be affected by this RFC at all, and neither are you, > since > > we use throwing error handlers. But ppl that do rely on code bases that > > have undefined vars "by design" will be. I would bet that the number of > ppl > > in that affected group and that also use a static analyser is very very > > small. This means that static analysers are not a pragmatic solution > here. > > That. > > > Ppl that don't use static analysers deserve a prior notice. There is a > > dedicated reporting mechanism in place and we should use it IMHO. With > new > > deprecations added to PHP 8.1, the ecosystem realized that the tooling > > needed to improve - and it did (phpunit, Laravel, etc.). We can and > should > > add new runtime deprecations when planning a BC break. > > > > Please consider adding this deprecation Mark (and others.) > > Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I > wouldn't be happy either way. > I mean in addition yes, deprecation before warning. I considered grouping them as E_DEPRECATED|E_WARNING but that'd break many userland error handlers I fear.
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 23.02.2022 at 16:29, Nicolas Grekas wrote: > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit : > >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < >> nicolas.grekas+...@gmail.com> wrote: >> >>> But this makes me think: we should trigger a deprecation just before all >>> corresponding warnings! >> >> Please, no more deprecation warnings, make it stop >> Yes, undefined variables are a problem, but I just spent 6 months in >> `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but >> frustration: this stuff is statically introspectible, and even more >> side-effects are just more trouble. > > I'm not going to be affected by this RFC at all, and neither are you, since > we use throwing error handlers. But ppl that do rely on code bases that > have undefined vars "by design" will be. I would bet that the number of ppl > in that affected group and that also use a static analyser is very very > small. This means that static analysers are not a pragmatic solution here. That. > Ppl that don't use static analysers deserve a prior notice. There is a > dedicated reporting mechanism in place and we should use it IMHO. With new > deprecations added to PHP 8.1, the ecosystem realized that the tooling > needed to improve - and it did (phpunit, Laravel, etc.). We can and should > add new runtime deprecations when planning a BC break. > > Please consider adding this deprecation Mark (and others.) Do you mean E_DEPRECATED in addition to E_WARNING, or instead? I wouldn't be happy either way. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit : > On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas < > nicolas.grekas+...@gmail.com> wrote: > >> >> But this makes me think: we should trigger a deprecation just before all >> corresponding warnings! >> > > Please, no more deprecation warnings, make it stop > Yes, undefined variables are a problem, but I just spent 6 months in > `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but > frustration: this stuff is statically introspectible, and even more > side-effects are just more trouble. > I'm not going to be affected by this RFC at all, and neither are you, since we use throwing error handlers. But ppl that do rely on code bases that have undefined vars "by design" will be. I would bet that the number of ppl in that affected group and that also use a static analyser is very very small. This means that static analysers are not a pragmatic solution here. Ppl that don't use static analysers deserve a prior notice. There is a dedicated reporting mechanism in place and we should use it IMHO. With new deprecations added to PHP 8.1, the ecosystem realized that the tooling needed to improve - and it did (phpunit, Laravel, etc.). We can and should add new runtime deprecations when planning a BC break. Please consider adding this deprecation Mark (and others.) Nicolas >
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas wrote: > > But this makes me think: we should trigger a deprecation just before all > corresponding warnings! > Please, no more deprecation warnings, make it stop Yes, undefined variables are a problem, but I just spent 6 months in `vendor/` code for 8.0->8.1 stuff, and it doesn't bring anything but frustration: this stuff is statically introspectible, and even more side-effects are just more trouble. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.io/
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le mar. 22 févr. 2022 à 12:07, Mark Randall a écrit : > On 22/02/2022 09:15, Nicolas Grekas wrote: > > I very much call for an implementation to be provided before starting any > > vote on the topic btw. > The RFC states on its first line that accessing an undefined variable > emits an E_WARNING. If it does not currently emit an E_WARNING then it > is out of scope of this RFC. > This last sentence could be worth copy/pasting into the RFC :) Thanks for the recent edits, they help clarify to me. > It is not sensible to provide a full implementation for something that > will require extensive engine and test changes for something several > years into the future, during which many other changes will be made. > > A sensible time for this would be after the branch is cut for 8.4. > I understand if the target is to do everything in 9.0. But this makes me think: we should trigger a deprecation just before all corresponding warnings! This would signal the change to 8.x users and help them spot where a change is needed. This should happen before the warning to that error handlers that turn the warning into an exception also get a note about the soon-to-be change. WDYT? Nicolas
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
I have tried to no avail to be removed from this list. So I will just spam this until I am removed. On Tue, Feb 22, 2022, 3:15 AM Nicolas Grekas wrote: > Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a > écrit : > > > On 17/02/2022 23:28, Mark Randall wrote: > > > I present: > > > > > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > > > > > It would be good to have a "Scope" or "Unaffected Functionality" section > > here, because there are a number of closely related things which were > > also raised from Notice to Warning in 8.0: > > > > - undefined array keys > > - undefined object properties > > - array access on a non-array > > - property access on a non-object > > > > I think it is sensible to discuss those separately, but it would be good > > to make that clear. > > > > > > Similarly, it would be good to have more discussion of what "accessing" > > means, as the current examples are quite narrow, only showing direct use > > and the ++ operator. Other functionality potentially affected: > > > > - passing the variable to a function, presumably excluding by-reference > > parameters which don't currently warn > > - all the combined assignment operators - > > https://www.php.net/manual/en/language.operators.assignment.php > > - the array append operator ($a[] = 42;) does NOT currently give an > > undefined variable Warning > > - variable variables, e.g. "$b = 'a'; echo $$b;" > > - the compact() pseudo-function > > > > There's probably others that I've missed. > > > > I 100% agree with that. An "Unaffected Functionality" section would be much > welcome. > > I would add to the list: isset($foo) when $foo is first seen. > (To me this should not throw anything, like for uninitialized properties.) > > If the RFC is about promoting the current warnings to Error without adding > any other Error at places that currently don't throw any warnings, then it > could be useful to say so. And if the RFC is going to propose to throw > Error at places that are currently warning-less, the list should be > explicit. > > I very much call for an implementation to be provided before starting any > vote on the topic btw. > This is typically the kind of topic where getting into the actual code > might help spot edge cases. > > Thanks for the RFC btw! > > Nicolas >
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 11:23, Rowan Tommins wrote: - undefined array keys - undefined object properties - array access on a non-array - property access on a non-object I'd encourage those to be discussed, but they are unrelated to this RFC. I think most of them would pass fairly easily, but undefined array keys is out the outlier and has a reasonable chance of being rejected at this time. However, with their being 4 years before the launch of 9.0 (and the next opportunity to change it) opinion may change between now and then. I've updated the RFC to define accessing a variable as attempting to read its value for use in an expression without accounting for the possibility of it being unset. I have also included the warning message to narrow this down further, and noted that things which account for undefined variables such as isset, empty and null coalesce will remain unaffected. If there's am existing formal definition someone wishes to contribute, I'd be happy to update it. One thing maybe worth mentioning is that while most operators such as ++, +=, .= etc will be covered by this change, $undefined[] = 1; will not be. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 22/02/2022 09:15, Nicolas Grekas wrote: I very much call for an implementation to be provided before starting any vote on the topic btw. The RFC states on its first line that accessing an undefined variable emits an E_WARNING. If it does not currently emit an E_WARNING then it is out of scope of this RFC. It is not sensible to provide a full implementation for something that will require extensive engine and test changes for something several years into the future, during which many other changes will be made. A sensible time for this would be after the branch is cut for 8.4. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a écrit : > On 17/02/2022 23:28, Mark Randall wrote: > > I present: > > > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > > It would be good to have a "Scope" or "Unaffected Functionality" section > here, because there are a number of closely related things which were > also raised from Notice to Warning in 8.0: > > - undefined array keys > - undefined object properties > - array access on a non-array > - property access on a non-object > > I think it is sensible to discuss those separately, but it would be good > to make that clear. > > > Similarly, it would be good to have more discussion of what "accessing" > means, as the current examples are quite narrow, only showing direct use > and the ++ operator. Other functionality potentially affected: > > - passing the variable to a function, presumably excluding by-reference > parameters which don't currently warn > - all the combined assignment operators - > https://www.php.net/manual/en/language.operators.assignment.php > - the array append operator ($a[] = 42;) does NOT currently give an > undefined variable Warning > - variable variables, e.g. "$b = 'a'; echo $$b;" > - the compact() pseudo-function > > There's probably others that I've missed. > I 100% agree with that. An "Unaffected Functionality" section would be much welcome. I would add to the list: isset($foo) when $foo is first seen. (To me this should not throw anything, like for uninitialized properties.) If the RFC is about promoting the current warnings to Error without adding any other Error at places that currently don't throw any warnings, then it could be useful to say so. And if the RFC is going to propose to throw Error at places that are currently warning-less, the list should be explicit. I very much call for an implementation to be provided before starting any vote on the topic btw. This is typically the kind of topic where getting into the actual code might help spot edge cases. Thanks for the RFC btw! Nicolas
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Thanks! That’s all really useful information! Are we sure we want to change a language idiom though? The warning is useful (you can choose to ignore/suppress it or not) for most of us, that’ll result in better code. But it is a useful idiom. Get Outlook for iOS<https://aka.ms/o0ukef> From: Rowan Tommins Sent: Friday, February 18, 2022 2:56:07 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion On 18/02/2022 12:31, Mark Randall wrote: > I would claim that the unary operators behave slightly different, if > it were a case of cooerce to zero, the behaviour of null++ and null-- > would be expected to be the same as operating on 0, but it's not. > > null++ is allowed, but null-- returns null, and its value afterwards > is null. > > https://3v4l.org/Bnb2D It is "--" that is the odd one out here, not "++". Every other arithmetic operator in the language treats null as equivalent to 0. As far as I can tell, the fact that "$a--" behaves differently from "$a -= 1" is an implementation bug that's been around so long it's become documented behaviour. I tried to propose changing it, but the reaction degenerated into personal abuse, so I abandoned it. >> If anything, it's the fact that $a++ is NOT a special case that means >> it will be affected by this proposal. > > It is intended to be affected by this proposal. I didn't say it wasn't intentional, I said it wasn't special; the exact same behaviour applies to about a dozen operators which have to read the current value before writing. Concatenation, for instance, treats null as an empty string, so this currently works (with a Warning) even if $message is undefined: $message .= "Another thing happened\n"; Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 12:31, Mark Randall wrote: I would claim that the unary operators behave slightly different, if it were a case of cooerce to zero, the behaviour of null++ and null-- would be expected to be the same as operating on 0, but it's not. null++ is allowed, but null-- returns null, and its value afterwards is null. https://3v4l.org/Bnb2D It is "--" that is the odd one out here, not "++". Every other arithmetic operator in the language treats null as equivalent to 0. As far as I can tell, the fact that "$a--" behaves differently from "$a -= 1" is an implementation bug that's been around so long it's become documented behaviour. I tried to propose changing it, but the reaction degenerated into personal abuse, so I abandoned it. If anything, it's the fact that $a++ is NOT a special case that means it will be affected by this proposal. It is intended to be affected by this proposal. I didn't say it wasn't intentional, I said it wasn't special; the exact same behaviour applies to about a dozen operators which have to read the current value before writing. Concatenation, for instance, treats null as an empty string, so this currently works (with a Warning) even if $message is undefined: $message .= "Another thing happened\n"; Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 10:50, Rowan Tommins wrote: Other than an optimised implementation, there's nothing particularly special about the ++ operator's handling of null, it behaves the same as any other arithmetic operator: I would claim that the unary operators behave slightly different, if it were a case of cooerce to zero, the behaviour of null++ and null-- would be expected to be the same as operating on 0, but it's not. null++ is allowed, but null-- returns null, and its value afterwards is null. https://3v4l.org/Bnb2D If anything, it's the fact that $a++ is NOT a special case that means it will be affected by this proposal. It is intended to be affected by this proposal. -- Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 17/02/2022 23:28, Mark Randall wrote: I present: https://wiki.php.net/rfc/undefined_variable_error_promotion It would be good to have a "Scope" or "Unaffected Functionality" section here, because there are a number of closely related things which were also raised from Notice to Warning in 8.0: - undefined array keys - undefined object properties - array access on a non-array - property access on a non-object I think it is sensible to discuss those separately, but it would be good to make that clear. Similarly, it would be good to have more discussion of what "accessing" means, as the current examples are quite narrow, only showing direct use and the ++ operator. Other functionality potentially affected: - passing the variable to a function, presumably excluding by-reference parameters which don't currently warn - all the combined assignment operators - https://www.php.net/manual/en/language.operators.assignment.php - the array append operator ($a[] = 42;) does NOT currently give an undefined variable Warning - variable variables, e.g. "$b = 'a'; echo $$b;" - the compact() pseudo-function There's probably others that I've missed. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 08:51, Mark Randall wrote: The only reason this works at all is because an undefined variable read falls back to null, and the increment operator is hardcoded to treat null++ as 1. Other than an optimised implementation, there's nothing particularly special about the ++ operator's handling of null, it behaves the same as any other arithmetic operator: - Reading an undefined variable gives null - Coercing null to an integer gives 0 - Adding 1 to 0 gives 1 So the following all have the same result: unset($a); $a = $a + 1; unset($a); $a += 1; unset($a); $a++; unset($a); ++$a; If anything, it's the fact that $a++ is NOT a special case that means it will be affected by this proposal. Regards, -- Rowan Tommins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 07:48, Robert Landers wrote: Just out of curiosity, why is the 3rd case being included here? Is it just because it's currently a warning > When I first taught PHP in 2011, I was told > post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1` This is not the case, there is no isset($var) involved - specficially isset($var) would first check if a variable exists and is not null (ISSET_ISEMPTY_CV), it is designed to handle undefined variables, where as most things are not. Before the increment can happen, the value in the variable must first be read. This leads to the E_WARNING for accessing an undefined variable just like any other, which this RFC seeks to prohibit. The value is then copied internally, the original value is incrementeted, and the unchanged copy is returned (its value before incrementing). The only reason this works at all is because an undefined variable read falls back to null, and the increment operator is hardcoded to treat null++ as 1. That's why if you do this: $x = $foo++; var_dump($x); You get: Warning: Undefined variable $foo in on line 3 NULL Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
Hi Mark, Just out of curiosity, why is the 3rd case being included here? Is it just because it's currently a warning? The current behavior is well documented and known since ... forever? When I first taught PHP in 2011, I was told post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1` and if I wanted different behavior I needed to write it out. Maybe that original behavior was unintentional, but this seems like a pretty fundamental change to something that has been that way since the beginning just to "make it work like other languages"? Robert Landers Software Engineer Utrecht NL On Fri, Feb 18, 2022 at 12:28 AM Mark Randall wrote: > Internals, > > Following on from my previous thread, I think we are now in a position > where we can begin formal discussions on an RFC to promote undefined > variables to Error exceptions in PHP 9.0. > > I present: > > https://wiki.php.net/rfc/undefined_variable_error_promotion > > I still intend to bring other error promotions forward, potentially in > collaboration with other developers, but as this is the biggest change, > and the most likely to attract a large number of comments, I thought it > deserving of a standalone RFC. > > Mark Randall > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
[PHP-DEV] [RFC] Undefined Variable Error Promotion
Internals, Following on from my previous thread, I think we are now in a position where we can begin formal discussions on an RFC to promote undefined variables to Error exceptions in PHP 9.0. I present: https://wiki.php.net/rfc/undefined_variable_error_promotion I still intend to bring other error promotions forward, potentially in collaboration with other developers, but as this is the biggest change, and the most likely to attract a large number of comments, I thought it deserving of a standalone RFC. Mark Randall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
