Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:108902
To: internals@lists.php.net
References: <3f615d82-a84b-697b-5c02-8d915270f92c@gmail.com>
 <1f7d2c72-376a-c9f4-0e65-f6374ab0abfa@gmail.com>
Date: Sun, 8 Mar 2020 20:01:01 +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: <1f7d2c72-376a-c9f4-0e65-f6374ab0abfa@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] Increment/Decrement Fixes
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-108902@news.php.net>

On 08/03/2020 19:31, Rowan Tommins wrote:
> On 01/03/2020 21:23, Rowan Tommins wrote:
>> https://wiki.php.net/rfc/increment_decrement_fixes 

It reads better than before.

IMO option c) is definitely the absolutely superior option for the 
long-term health of the ecosystem, of that I have absolutely no doubt at 
all.

Simply, if it's arithmatic on something that's not a number, and isn't 
an overloaded object, it should throw.

But that seems like it's too far away... so I could *maybe* get behind 
subtracting from null becoming -1, but I really don't like it.

It just feels so wrong, but the only thing that feels worse is that we 
probably couldn't pass removing null++, at least in the base version, 
and that may set up null-- as the least-worst option.

--
Mark Randall