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 <rowan.coll...@gmail.com> Sent: Friday, February 18, 2022 2:56:07 PM To: internals@lists.php.net <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
