If conditions continue to be evaluated even after the "if" has been satisfied

Function XYZ()
  print "Why evaluating XYZ?  The If condition was already satisfied."
  XYZ = false
End Function

Sub XXX
  If true Or XYZ() Then
    print "True"
  End If
End Sub

Doing something like this and don’t want/need to evaluate subsequent conditions once the “If” is satisfied.

If ( _
( (X = "A") ) Or _
( (X = "B") And  Not (Yn = Ys) ) Or _
( (X = "C") And  Not (Mn = Ms) ) Or _
( (X = "D") And  Not (Qn = Qr) ) Or _
) Then
  do this ...
End If

If X is “A” do this…
If X is “B” And Yn does not equal Ys do this…
If X is “C” And Mn does not equal Ms do this…
If X is “D” And Qn does not equal Qr do this…

Why even when X is satisfied by “A” the subsequent conditions continue to be evaluated?

Is this an intended behavior with some purpose?

Basic has no boolean short circuiting. See tdf#153142. IMO, it is unfortunate; but implementing it now would be an incompatible change, because current code could rely on the unconditional side effects of all the expressions.

1 Like

Maybe an option flag with default to current behavior.

I don’t see a compelling reason. It would introduce incompatibility with other versions and apps (AOO) - and it would not make anything possible that wasn’t possible earlier. This is just a syntax sugar, allowing to express the same functionality in a different form, having its own price. It would be nice if it existed from the beginning, but it doesn’t worth it at this time.

Order of “If” conditions in high iteration loops can be a huge difference.
Avoid high cost evaluations by preceding with a simple test to exclude.

What do you mean? Are you explaining what could be simplified by the short-circuiting? Isn’t it clear that it’s obvious? But my point was, that it is already possible, just using a bit more elaborate syntax? So the proposal, while could provide a bit shorter expressions, does not introduce anything that wasn’t yet possible in the language using a different syntax.