Your example "-$a * $a" isn't at all the same because -$a doesn't produce side-effects, only output.
I never said that the compiler might magically produce differing results for the same input. I said that the language's definition does not declare a defined behavior for such expressions with combined side effects. As to reverting commits. When the initial commit was made in haste during an active discussion, a revert is entirely appropriate and has nothing to do with placing one's opinion over another's. It has to do with placing the process of consensus building over unilateral cowboy commits. -Sara On Fri, Jul 19, 2013 at 10:08 PM, Sherif Ramadan <theanomaly...@gmail.com>wrote: > > Sara, > > On Sat, Jul 20, 2013 at 12:44 AM, Sara Golemon <poll...@php.net> wrote: > >> What's undefined isn't the relationship between preinc/postinc and add. >> What's undefined is the use of multiple preinc/postinc operators within a >> single expression >> > > I'm sorry but I can not find any evidence of how that is undefined. The > operators are right-associative, with a defined level or precedence. Their > operands are well defined and their return value in the expression is > determined by the compiler, not the parser. In this sense the compiler > always executes those opcodes first and returns a temporary variable. > > >> (preincrements in particular). Our parser grammer, as it currently >> stands, does have a predictable order, but that is a side-effect of >> implementation. The language's definition of order of resolution of >> multiple preinc/postinc elements within a single ticked statement is that >> they are undefined. And *that* is what made your *particular* change to >> the documentation incorrect. >> > > The parser grammar in general is pretty muddled, I will agree with that. > However, the precedence order here is well defined within the expression. I > can not see any condition under which the compiler will introduce > unpredictable order of these opcodes or their results. > > >> >> If you'd like to define behavior for: echo ++$a + 1; then that's a >> different matter. Defining the behavior of ++$a + $a++, however is >> inviting misunderstanding*. >> >> What was inappropriate, was asking for comment, receiving comment which >> cited an issue, then committing without discussing that issue first. >> >> -Sara >> >> * Even if, technically, either order of evaluation will result in the >> same answer for this contrived expression. ++$a * $a++ is a more obviously >> ambiguous answer for a language which explicitly does not define an order >> of resolution. >> > > By that logic we should indicate that -$a * $a is also undefined behavior? > I know the parser grammar is not well-defined and I'm taking this fact into > consideration, but here we are talking about operators which will compile > down into very much well-defined opcodes and have a predictable order of > resolution. It's quite possible that someone could introduce a change later > on that will cause a different result, but the likelihood of that becoming > a reality is slim-to-none. > > I'm not a fan of getting into cat and mouse games over these types of > discussions, however. I posed my opinion on this matter and I refuse to > overwrite someone's commit because I feel my opinion is the only one that > counts. I am certainly not above being wrong. I just want to be sensible. > > >> >> >> On Fri, Jul 19, 2013 at 9:28 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: >> >>> Hi Sara, >>> >>> 2013/7/20 Sara Golemon <poll...@php.net> >>> >>>> On Fri, Jul 19, 2013 at 7:16 PM, Yasuo Ohgaki <yohg...@ohgaki.net>wrote: >>>> >>>>> >>>>> >>>>> If there aren't comments, I'll rewrite the example. >>>>> >>>>> >>>>> There were comments. I explicitly told you that that the behavior is >>>> defined as undefined. You CHOSE to ignore that comment. You CHOSE to >>>> break the documentation. >>>> >>> >>> If there is defined precedence, arithmetic operation should follow it. >>> If there is exception, it should be documented. >>> >>> I don't understand why/how the arithmetic operation can be >>> ambiguous with defined precedence. (++ and -- are higher than +) >>> >>> $a = 1; >>> echo ++$a + $a++; >>> >>> should always print 4 with current PHP precedence definition. >>> If it does not, it's a bug in language. >>> >>> // mixing ++ and + produces undefined behavior >>> $a = 1; >>> echo ++$a + $a++; // may print 4 or 5 >>> >>> I don't see any reason it became undefined. >>> If this kind of simple precedence is broken, how programmers write >>> code and/or trust the language? >>> >>> http://3v4l.org/mR4da/vld#tabs >>> >>> This site seems support PHP 4.3.0 to PHP 5.5.0 and opcode looks >>> fine. Am I missing something? >>> >>> If you would like to suggest use of (), it should be done differently. >>> IMHO. >>> The comment only ruins PHP's reputation as language. >>> >>> Regards, >>> >>> -- >>> Yasuo Ohgaki >>> yohg...@ohgaki.net >>> >> >> >
