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

Maybe you didn't read my earlier messages. IAC I was pointing out those benefits are in my experience. YMMV.

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

Non-existent? You pointed out the docs that explicitly said VFP supports LTR - no exceptions were noted there. It only came up later that the SQL engine may be "exempt" from that rule. It bit Peter - cost him a day to track it down - just what would you call it? Is it one of MS's famous "it's a feature, not a bug"?

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

I'm glad to see your knowledge of the internals of the SQL engine is so great that you can predict in advance what the results of all of the above tests are. Me, I'm not so sure. But the point is, I don't care, and it can't affect me because I don't rely on it. I call it caution, you call it FUD - whatever.

You seem not to understand why LTR was invented in the first place. It was designed as a speed optimization in the days when computers were slow and expensive. To this day, that's its reason to exist. If you want to continue to use a side-effect of that optimization for flow control in your programs, do so at your own risk.

It's actually pretty ironic that in another message Peter is arguing that internal code optimization must obey language rules, when this "rule" is simply a side-effect of an optimization in the first place.