Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68263
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <51EA3E36.1090402@sugarcrm.com>
References: <CAGa2bXbWCKBx1=x0Jmo0=L0ixkSx28J4vf71i0g=PHdAyStc4Q@mail.gmail.com>
	<51EA3E36.1090402@sugarcrm.com>
Date: Sat, 20 Jul 2013 03:59:59 -0400
Message-ID: <CAL+t6cEHoZubOFMszMDaB8deByKGbA7HCx+3PVuLTFKZCE0TMA@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Yasuo Ohgaki <yohgaki@ohgaki.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=e89a8ff1ccae7164d404e1ecd4e1
Subject: Re: [PHP-DEV] Operator precedence is undefined?
From: theanomaly.is@gmail.com (Sherif Ramadan)

--e89a8ff1ccae7164d404e1ecd4e1
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Jul 20, 2013 at 3:37 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:

> Hi!
>
> > I cannot believe this is true now, but I ask list before I fix doc.
>
> I don't think there's something that needs to be fixed. "Undefined"
> means "it depends on implementation and we do not want to commit to a
> specific behavior here because implementations may change". This is a
> fair warning against using implementation details that are not promised
> to stay fixed and later crying why next PHP version broke your code.
> Because you used undefined behavior. If the behavior is specified as
> undefined, that means "don't do this" - so you know it may be broken,
> and write better code instead that is not broken.
>
>

Stas,

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 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 clear warning of "undefined
behavior" in the manual? References being one example.

I'm just suggesting that we carefully consider our arguments and not only
acknowledge them when they work out to our benefit and then discard them
the moment they don't support our cause. Clearly there is an argument here
that this is acceptable behavior and clearly there is an argument that it
is undefined. The real question is whether or not its worth specifying as
"undefined behavior" in the manual. A single line comment in an example
like that which states "may print 4 or 5" is not good documentation. My
suggestion is either clarify in an actual note or section of that
documentation why it is considered undefined behavior or to remove the
comment.

There is unquestionable signs of confusion coming from our users as the bug
report indicates. We should not ignore the fact that this comment has
confused somebody and should instead strive to improve it.

My suggestion would be to ad some clarifying language here:

"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."

--e89a8ff1ccae7164d404e1ecd4e1--