short-circuiting

Suppose I want to check a bunch of objects to make sure none is null: if (obj != null && obj.Parameters != null && obj.Parameters.UserSettings != null) { // do something with obj.Parameters.UserSettings } It is an alluring prospect to write a helper function to accept a variable number of arguments and simplify this kind of check: static bool NoNulls(params object[] objects) { for (int i = 0; i < objects.Length; i++) if (objects[i] == null) return false; return true; } Then the above code could become: if (NoNulls(obj, obj.Parameters, obj.Parameters.UserSettings)) { // do something } Right?

I have multiple expensive functions that return results. I want to return a tuple of the results of all the checks if all the checks succeed. However, if one check fails I don't want to call the later checks, like the short-circuiting behavior of and . I could nest if statements, but that will get out of hand if there are a lot of checks. How can I get the short-circuit behavior of and while also storing the results for later use? def check_a(): # do something and return the result, # for simplicity, just make it "A" return "A" def check_b(): # do something and return the result, # for

From Wikipedia: Lazy evaluation is: In programming language theory, lazy evaluation or call-by-need is an evaluation strategy which delays the evaluation of an expression until its value is needed Short-circuit evaluation is: Short-circuit evaluation, minimal evaluation, or McCarthy evaluation denotes the semantics of some Boolean operators in some programming languages in which the second argument is only executed or evaluated if the first argument does not suffice to determine the value of the expression So what's the difference between them for example when I have: if(false && true && true)

Reading up a bit on Java 8, I got to this blog post explaining a bit about streams and reduction of them, and when it would be possible to short-circuit the reduction. At the bottom it states: Note in the case of findFirst or findAny we only need the first value which matches the predicate (although findAny is not guaranteed to return the first). However if the stream has no ordering then we’d expect findFirst to behave like findAny . The operations allMatch , noneMatch and anyMatch may not short-circuit the stream at all since it may take evaluating all the values to determine whether the

#include <type_traits> #define FORWARD(arg)\ std::forward<decltype(arg)>(arg) template<typename... Args> constexpr bool AndL(Args&&... args) { return (... && FORWARD(args)); } template<typename... Args> constexpr bool AndR(Args&&... args) { return (FORWARD(args) && ...); } int main() { bool* pb = nullptr; false && (*pb = true); // ok at runtime. AndL(false, (*pb = true)); // error at runtime! AndR(false, (*pb = true)); // error at runtime! } The traditional && operator supports short-circuit evaluation , so false && (*pb = true) will be ok at runtime, but the following two cases are not. How

I was messing around with fix and after messing around with it I came across some weird behavior, namely that 0 * undefined is *** Exception: Prelude.undefined and undefined * 0 is 0 . Which also means that fix (0 *) is *** Exception: <<loop>> and fix (* 0) is 0 . After playing around with it it seems like the reason is because it is non-trivial to make it short circuit in both directions, as that doesn't really make much sense, without some sort of weird parallel computation and start with the first non-bottom returned. Is this kind of thing seen in other places (reflexive functions that aren