>>>Some languages are guaranteed to support left-to-right conditional execution as you outlined in your original message. AFAIK xBASE/VFP is NOT one of them - I don't recall ever seeing any official confirmation of this, either in documentation or by Microsoft. If that's the case there's no need to document this behaviour because you shouldn't be relying on it in the first place.
>>
>>It's documented in VFP help http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_foxhelp9/html/4fcfebe5-0fbe-41da-96ed-ecaa25a6bf23.asp?frame=true :
>>
>>"Visual FoxPro evaluates logical expressions from left to right, and only for as long as necessary".
>
>Thanks for the link! I wasn't aware VFP guarantees this.
>
>>It may not be true for the SQL conditions though because query optimizer may rearange them.
>
>Agreed. You and Peter are right, that this deviation from LTR processing support should be documented.
>
>>>Personally I never use left-to-right conditional execution even in languages that explicitly support it. IMO it makes code hard to understand and is a significant source of nasty bugs. Not to mention that these days, vendors are working hard on optimizing compilers which, if they're at all buggy, will likely have effects like you've seen here. Just say no ;)
>>
>>I've to disagree with you. I use it all the time. If used properly, it makes code simpler, easier to read and maintain. I never encounter any bugs related to it.
>
>I think we will have to agree to disagree on this. I believe the following two lines of code should always have the same answer and same effect on the application's environment:

x = foo() AND bar()
>x = bar() AND foo()

IMO the only valid reason for ordering logical operands is for speed optimization i.e. if foo() executes faster than bar() and evaluates to .F. often enough to make putting it first worthwhile. This is why LTR processing was devised in the first place.
>
>For sure, "simpler, easier to read and maintain" is a matter of taste. Sometimes I've been tempted to use LTR, or (more often) inadvertently built logical code that (unknown to me) relied on LTR processing under some input conditions. After refactoring to eliminate reliance on LTR, I have always, without exception, been very glad I did.
>
>Relying on LTR for flow control is implying nested logic rather than explicitly stating it, which I consider unnecessarily terse and (IMO) hard to read. If you're building complex logic from a truth table it's more difficult to confirm, with LTR, that you've implemented the truth table properly. For me, when the logic is explicitly laid out I find it much easier, 6 months from now, to revisit the code for debugging or enhancement.

I can imagine your POV, because you thought that LTR was not a guaranteed part of the language.