Hugo Kornelis (2/1/2013)
That all being said - one other poster (I think it was Tom, but not sure anymore) found a smart way to extend Jeff's method to raise an error if the code would generate incorrect results. Again, buried somewhere in these forums. This is, of course, still firmly in undocumented and unguaranteed territory - but I looked very long and very hard at his trick, and I dare to say with 99.9999% certainty that his claim is reliable - code that employs Tom's trick will either populate correct results, or generate an error.
The original suggestion for error checks was Paul White's, but several people (including Paul himself, as well as both you and me) felt that it still left room for incorrect results without throwing an error. I suggested an improved check which would make the reliability of throwing an error when evaluation order was not as required to deliver correct results very close to 100%. To use a different order but not throw an error the data engine would have to do something quite bizarre, in fact I believe it would have to combine attributes from two different rows when doing a projection, which is of course forbidden by the semantics of projection. While of course T-SQL doesn't conform to the relational model's requirements for its relational calculus, I don't believe that it diverges so far from those requirements as to change the semantics of projections, so I believe the chance of getting incorrect results instead of an error is pretty much the same as the chance of finding an as yet unknown bug that makes some feature that is long established and formally documented in the language definition deliver incorrect results when confronted some unusual data, which might be as high as one in a million (as suggested by your 99.9999%). 😎
Tom