Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92099
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
To: internals@lists.php.net
References: <CAGN=FiSPHpnBv2SHLWTQfrZUcOyqkDORn+rpuhDNSr+D+JGpCw@mail.gmail.com>
 <CAESVnVqa1g_BGFqJAHjTuAJ6WYM-PWgvTt8OP1GnQJmkey=wog@mail.gmail.com>
Message-ID: <5703AA3B.4010000@gmail.com>
Date: Tue, 5 Apr 2016 13:06:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <CAESVnVqa1g_BGFqJAHjTuAJ6WYM-PWgvTt8OP1GnQJmkey=wog@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Copy On Write and Assign By Reference perform different
 on PHP5 and PHP7
From: rowan.collins@gmail.com (Rowan Collins)

Sara Golemon wrote on 01/04/2016 02:52:
> On Thu, Mar 31, 2016 at 9:47 AM, Huqiu Liao <liaohuqiu@gmail.com> wrote:
>> I have a question about Assign By Reference and I posted on StackOverflow,
>> I'd like to know the reason behind it, and I did not get any this kind of
>> answer, can anyone give me some clues.
>>
> Are you asking out of curiosity? Or because you think a new bug has
> been introduced in PHP7?
>
> If the latter, I'd respond by pointing out that the behavior of using
> multiple operations with side-effects (like pre/post inc/dec) is
> defined as undefined.  That is, while the PHP reference implementation
> may give you a particular result, you should not rely on that result.
>


I just dug into the spec out of curiosity, and I have a nit-pick: there 
is relevant language under "Section 10: Expressions" [1]:

 > Unless stated explicitly in this specification, the order in which 
the operands in an expression are evaluated relative to each other is 
unspecified. [...] (For example,[...] in the full expression $j = $i + 
$i++, whether the value of $i is the old or new $i, is unspecified.)

But arguably this doesn't go far enough to justify the PHP 5 engine's 
behaviour in this case, because it only mentions the *order* of 
evaluation being unspecified, not the actual semantics. The definition 
of the pre-increment operator [2] states:

 > The result is the value of the operand after it has been incremented.

That is, the operator does not return the operand itself, but its value 
at a particular time. However, there is no order of execution which 
allows the value of the variable to be 4 on both sides of the addition; 
to get this requires the actual behaviour of the ++ operator to be 
re-defined as "return a reference to the incremented operand". (You 
could make an argument for the two increments happening "simultaneously" 
and giving a result of 6, but to get 8, they have to both happen 
simultaneously *and* see each other's results.)

I'm not seriously suggesting that the PHP 5 behaviour is problematic, 
but unless there are additional caveats somewhere else, it does seem to 
violate the letter of the current spec.

[1] https://github.com/php/php-langspec/blob/master/spec/10-expressions.md
[2] 
https://github.com/php/php-langspec/blob/master/spec/10-expressions.md#prefix-increment-and-decrement-operators

Regards,
-- 
Rowan Collins
[IMSoP]