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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
