>Well, the docs say it's supposed to be, but you've already found one instance where it isn't. If you didn't rely on LTR you wouldn't have wasted part of you life dealing with the problem you had.

It's odd argument. If follow it we shouldn't rely on any language rules because they could theoreticaly be be broken somewhere.

>The reasons I laid out above are separate from my previously not knowing that LTR is "guaranteed". For me, these benefits accrue whether VFP or another language guarantees LTR support - I still won't use it unless I'm tweaking for maximum performance, and I still arrange logic so (foo() AND bar()) has the same effects as (bar() AND foo()).

It would be nice to hear what those benefits are.

>
>The trend these days is towards more and more code optimizations behind the scenes. The VFP SQL engine is a perfect example. Many other language compilers and interpreters optimize as well; even at the processor level modern CPUs employ branch prediction, out-of-order and speculative execution. I imagine compiler and CPU designers consider LTR support a significant limitation on what they can do and would love to chuck it out. It doesn't surprise me that in some circumstances they would do just that (VFP SQL engine), or that in others their optimizations may have bugs that break LTR.

The VFP SQL engine doesn't support LTR because of the declarative nature of SQL language not because somebody choose to.
Why do you keep bringing up non-existing bugs in LTR implementation?

>I think FabioL might have some fun testing here :)
>- LTR in UDFs called from SQL engine
>- LTR in class methods called from SQL engine
>- LTR in UDFs in index expressions used in Rushmore
>- LTR in RI code (Rushmore or not)
>- Potential MTDLL issues
>- Combinations of the above
>- ...

You seems not to understand difference between SQL language and the rest of VFP. There's nothing to test because neither of logical expression in the above list is a part of any SQL statement.