Edit by strazer: Needed Scorp's post for another thread, so here's his message:"Lazy evaluation" (I don't like to call it that as it sounds rather negative - "short-circuit evaluation" is better I think) is not just in every modern compiler, it's written into the specification of languages...
Yeah, and I'm not against the lazy evaluation, but implementing it now (by means of changing how "&&"/"||" work) would mean the old code may not work as expected. It reminds me the situation with the mathematical operators of the same precedence, you have mentioned, that are evaluated right to left. And, to be honest, I've already written plenty of code relying on '&&' behaviour in AGS.

Ah well, I will then probably replace '&&' with '*' or '&'.
Of course, if '&&', '||' will be non-strict operators it must be very clearly stated in the manual, as Gilbert says, because in that case the order in which expressions are written does matter and, without being thought out, may hide mistakes to be revealed at run-time but only under certain conditions. I don't think many people scripting in AGS think about ordering such expressions at the moment.
'if' statements, on the other hand, make it intuitively clear as it all depends on nesting:
if (a) {
...
if (b) {
}
...
}
but...
if (b) {
...
if (a) {
}
...
}
There is, of course, an advange of lazy operators if we are too lazy to set up if-blocks

(especially in case of simple "(ptr != null && ptr.Func()") but for a complex stuff, nested 'if's would really save the time and efforts while debugging.
p.s. Just wanted to say that I think there is no disagreement about the desired behaviour in general as it all depends on what we are after, writing a certain portion of code.
/end Scorpiorus
Lazy evaluation should only chnage the behaviour of code using side-effect in function that are used in a && or || expression. One possibility is to change the behaviour only if Force OO scripting is set on, or to have ||| and &&& operators that are lazy.
For an example of side-effects, this code wouldn't work the same way any more, but then I'd never write code like this, given that it tends to be illegal in hardware description languages...
int glob;
function myfun (int x) {
glob =x;
return x*2;
}
if (a>5 && glob(x) >6) {
// do something
}