Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108662
References: <16481aca-93f4-43f5-5ec2-413d19ade318@gmail.com>
 <CAF+90c_pcOBH0PaADBeB8ShPVB6Jh5KGDU0eiQC-C=Ji8ZSGFA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Message-ID: <660551dc-4527-5f6e-1f05-e167931cd9f1@gmail.com>
Date: Tue, 18 Feb 2020 20:27:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c_pcOBH0PaADBeB8ShPVB6Jh5KGDU0eiQC-C=Ji8ZSGFA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] Allow null variables to be decremented
From: rowan.collins@gmail.com (Rowan Tommins)

On 18/02/2020 14:00, Nikita Popov wrote:
> Principally in favor of this change, I do think that ++ and -- should 
> behave consistently if nothing else. We might want to consider giving 
> the same treatment to false/true as well, which should be interpreted 
> as 0/1. That is $foo++ / $foo-- should behave the same ways as 
> $foo+=1, $foo-=1 for null, true, false. It seems odd to single out 
> only "null" here.
>
> Additionally I would suggest a notice when trying to increment arrays, 
> resources and objects, rather than just silently doing nothing. As 
> long as it's just a notice, this should have minimal BC implications.


Thanks. That seems a reasonably modest expansion, without getting into 
the deeper questions of string increments or fatal errors.

For the record, the reason I singled out null is that it's the only type 
where ++ and -- behave differently from each other.

With booleans, there is at least a consistency between those two 
operators, even though it's consistently weird. There's definitely a 
strong case for making them match +=1 and -=1 though.

Regards,

-- 
Rowan Tommins (né Collins)
[IMSoP]