Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68271
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender)
Message-ID: <51EAF928.3060604@sugarcrm.com>
Date: Sat, 20 Jul 2013 13:55:04 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Sherif Ramadan <theanomaly.is@gmail.com>
CC: Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXbWCKBx1=x0Jmo0=L0ixkSx28J4vf71i0g=PHdAyStc4Q@mail.gmail.com> <51EA3E36.1090402@sugarcrm.com> <CAL+t6cEHoZubOFMszMDaB8deByKGbA7HCx+3PVuLTFKZCE0TMA@mail.gmail.com>
In-Reply-To: <CAL+t6cEHoZubOFMszMDaB8deByKGbA7HCx+3PVuLTFKZCE0TMA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> I agree that we should not rush to commit changes in the midst of
> on-going discussion. However, I have to just add to this notion of
> undefined behavior that by your definition ALL of PHP is undefined
> behavior. Everything we do is an implementation detail. What

This is certainly not true. There's a lot of things explicitly
documented about PHP behavior, and those behaviors are well-defined.

> specification do we have that clearly defines PHP's behavior? Can you
> honestly tell me that we haven't changed behavior in the past despite no

Of course we changed behavior - languages change. We try not to change
documented behaviors, but in some occasions it is necessary. In this
case we tell people "we changed behavior because of these reasons".
Undefined behavior, on the other hand, can change anytime without much
notice and it is not considered BC break.

> clear warning of "undefined behavior" in the manual? References being
> one example.

One example of what?

> argument that it is undefined. The real question is whether or not its
> worth specifying as "undefined behavior" in the manual. A single line

There's no question here. We know it depends on internal implementation
and we know we do not want to commit to keeping specific behavior
exhibited now forever. This is what the manual is telling, and unless
you have some argument on why we must commit to it, it is not a
question, it is a fact about the state of affairs right now.

> "Using multiple increment/decrement operators in the same expression has
> no guaranteed order of resolution and is subject to change. Relying on
> code such as $a = 1; ++$a + $a++ === 4; is considered undefined behavior."

If you want to rewrite the text to make the points about what undefined
behavior is clearer - sure, please do it. However, it should still say
this behavior is undefined and you should avoid relying on current
implementation if you want your code to be robust.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227