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 >> > >
