The C# language has two "AND" operators when dealing with Boolean values, & and &&. (Leaving aside the bit-wise operators.)
When the left-hand value is False, the difference between these two operators regards the evaluation of the right operand.
(false && x) vs
(false & x)
&& means the right hand side must not be evaluated.
& means the right hand side must be evaluated.
Decades ago, you'd always use the equivalent of && because it would avoid spending the time uselessly processing that right-hand-side when we already know the answer. In this day and age however, we have CPUs that are already processing the next line of code before the previous line has finished. This has to come to a stop when a branch is reached, so you might want to use & to avoid that branch in the code and allow the CPU to speed ahead unimpeded.
(Two quick side-bars: Sometimes, you need to use && because the left hand side protects against unwanted side effects of the right hand side, such as checking NULL to avoid a null-reference error. I'll also acknowledge that the compiler may be smart enough to sometimes know that the right-hand of a && operation is side-effect-free so it can eliminate the branch instruction. These are beyond the scope of this question.)
So there's the background, here's my question.
Are there any languages or environments that have established a compromise between && and & that leave it up to the compiler/run-time to decide if the right-hand side needs to be evaluated?
a AND b, the programmer would be saying that the compiler/run-time may evaluate
b if a branch is too costly, but is also explicitly permitted to branch around the work of evaluating
b if doing so would be greater than the work of the branch instruction.