Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:79629
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.181 as permitted sender)
Message-ID: <548D0DD2.5060501@gmail.com>
Date: Sun, 14 Dec 2014 04:10:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <B6.00.14066.691CC845@pb1.pair.com> <alpine.DEB.2.11.1412132316440.4080@whisky.home.derickrethans.nl> <548CDF7F.3060805@gmail.com>
In-Reply-To: <548CDF7F.3060805@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Fix incorrect ternary '?' associativity for 7.0?
From: rowan.collins@gmail.com (Rowan Collins)

On 14/12/2014 00:53, Leon Sorokin wrote:
> Respectfully,
>
> PHP's 'Unexpected behavior is not a bug' stance is pretty infuriating
[...]
> Documentation of unexpected behavior does not make something 'not a bug'.

Whether or not this particular bug is fixable, I do agree with this: 
"we're not going to fix this because it's hard / too late" is not the 
same as "this is not a bug".

For instance, attempting to decrement a null value with the -- operator 
results in null, even though incrementing with ++ will result in int(1), 
and, even more bafflingly, using -= 1 will result in int(-1). This is 
documented behaviour, but with no rationale other than "it's always been 
that way". http://3v4l.org/bfsZ8 Apparently, this bug has been around 
since (at least) PHP 3, but does that really mean we're never allowed to 
fix it? At least the resolution to this report was "Won't Fix" rather 
than "Not a Bug": https://bugs.php.net/bug.php?id=20548

Personally, I consider the non-evaluation of arguments to undeclared 
constructors (see "Default constructors" RFC thread) to be another 
example (an unfortunate consequence of a valid optimisation, resulting 
in behaviour that nobody would have specified), although Stas disagrees.

As I mentioned in that other thread, one of the implications of saying 
"it's not a bug" is to assert that it's part of the *language* to work a 
particular way, and so should be specified and reproduced in other 
implementations (from tests on 3v4l.org, HHVM carefully replicates the 
null-- bug, but not the no-constructor lazy evaluation). Changing it 
then implies changing the language specification, and other 
implementations matching the appropriate version. If, on the other hand, 
we accept certain things as *bugs in the implementation*, then other 
implementations may diverge in behaviour anyway, and a new major version 
released on php.net could (in a sort of philosophical way) be considered 
a new implementation.

Now, the associativity of the ternary operator is presumably in the 
language specification already, and belongs there, as it's such a basic 
attribute of the operator. I'm also inclined to agree that the benefit 
may not outweigh the cost of fixing it at this stage, but I do think 
it's worth discussing.

-- 
Rowan Collins
[IMSoP]