Talk:Short-circuit evaluation

message: Can anyone motivate (with a reference) the term "minimal evaluation"? I've only seen this concept referred to as short-circuit evaluation (in compiler literature). Wouter Lievens 14:33, 19 May 2006 (UTC)
thread_title: Article title

message: Added a brief segue into problems that short-circuit evaluation may cause (not executing the second part of a conditional if that conditional is supposed to do something.), since every programming book I've ever seen mentions this at least briefly. Sloverlord 15:00, 25 October 2006 (UTC)
replies: text: ...and evaluate to 1 and 0. (which are sometimes considered as true and false) ca1 (talk) 00:36, 12 May 2008 (UTC)
thread_title:  Problems 

message: Quote:
 In others (C, Ada), both short-circuit and standard boolean operators are available.
What standard boolean operator is available in C? I didn't know C has boolean operators at all, just logical ones (difference being that a logical operator evaluates something to be logical true or false and a boolean operator evaluates to a typed true or false statement). I suppose you could write the first example as (assuming a and myfunc are both int and long has more bits):
    if ((long)a + (long)myfunc(b)) {
        do_something();
    }
This would cause a and myfunc to be evaluated and then convert to a larger type so the results can't overflow and get back to 0 so the addition acts like an &&, but I hardly think that anyone would consider + a boolean operator.
--216.37.197.174 14:42, 8 March 2007 (UTC)
thread_title:  Inaccuracy? 

message: This entire article needs to be cleaned up. The summary, main content, and examples all seem to be written by a computer science professor trying to justify his education. This fairly simple topic should be easy to understand by someone with a basic knowledge of programming but I fear this article is a lot harder to understand than it needs to be.  —Preceding unsigned comment added by 99.29.171.122 (talk) 17:21, 25 January 2010 (UTC)
thread_title:  Poorly written 

message: The Fortran language standard(s) (see e.g. section 6.6.1 of the FORTRAN77 or section 7.1.8.1 of the Fortran2003 standard) explicitely allow a 'processor' to perform short circuit evaluation. However, it is not required to happen. I am currently not sure, how to best represent this in the language overview table. Maybe with an entry of none in eager operators and .and., .or. in short-circuit operators combined with a footnote as for Pascal?
InfoBroker2020 (talk) 11:16, 12 May 2010 (UTC)
thread_title:  Incorrectness w.r.t. Fortran 

message: * ALGOL68 (WTF?) paragraph removed
 - irrelevant to the subject other than mentioning ALGOL - either rewrite it back in better fashion or keep it dead
 * minor editorial (weasels, cits etc)
 * ToC cleanup
 * unneeded example removed
 * code example simplified
cheers, and be bold, ppl. Vaxquis (talk) 19:07, 2 July 2010 (UTC)
thread_title:  cleanup 

message: The "&" in ruby is greedy --
irb(main):423:0> (1 == 2) & (Math::log(-1) < 2)
NoMethodError: undefined method `<' for (0.0+3.14159265358979i):Complex
	from (irb):423
	from /opt/local/bin/irb1.9:12:in `<main>'
:Exactly. It doesn't short-circuit. That's why it is listed under the Eager operators column in the table. --71.141.138.20 (talk) 05:55, 14 July 2010 (UTC)
replies: text: Indeed that was incorrect. I corrected it with a reference to . Matma Rex talk 18:29, 2 April 2024 (UTC)
thread_title: Ruby

message: What is listed under Eager operators are `and`/`or`. This is not correct. They do short-circuiting, too:
    def t ; puts "TRUE"  ; true  ; end
    def f ; puts "FALSE" ; false ; end
    puts "and:"
    f and t
    puts "or:"
    t or f
    puts "&&:"
    f && t
    puts "||:"
    t || f
The difference between `and`/`or` and `&&`/`||` is the precedence behaviour.
    [
      %w(or and),     # same precedence
      %w(|| &&),      # && has higher precedence
    ].each { |o,a|
      [true,false].each { |a1|
        [true,false].each { |a2|
          [true,false].each { |a3|
            r0 = "(#{a1} #{o}  #{a2}) #{a} #{a3} "
            r1 = " #{a1} #{o}  #{a2}  #{a} #{a3} "
            r2 = " #{a1} #{o} (#{a2}  #{a} #{a3})"
            e0 = eval r0
            e1 = eval r1
            e2 = eval r2
            next if e0 == e2
            puts "#{r0}   #=>  #{e0}"
            puts "#{r1}   #=>  #{e1}"
            puts "#{r2}   #=>  #{e2}"
            puts
          }
        }
      }
      puts
    }
Yet, the bitwise operators `&`/`|` don't short-circuit.
Bertram Scharpf — Preceding unsigned comment added by 77.186.148.237 (talk • contribs) 17:50, 2 April 2024 (UTC)
replies: text: Indeed that was incorrect. I corrected it with a reference to . Matma Rex talk 18:29, 2 April 2024 (UTC)
thread_title:  It is still wrong 

message: Java - the '?' operator definitely short-circuits
C# - the '?' operator probably short-circuits and the '??' (Null Coalescing) operator definitely does
Should the row in the table for "C#, Java, MATLAB R" be split up?  — Preceding unsigned comment added by 198.178.8.81 (talk) 21:23, 10 August 2012 (UTC)
thread_title:  Additional operators in Java and C# that short circuit 

message: Could someone please explain how Select/Case in VB is related to short-circuit evaluation?  As far as I can tell, it has nothing to do with it. --Macrakis (talk) 15:13, 18 December 2012 (UTC)
thread_title: Select/Case in VB

message: Shouldn't the table mention ternary operators like ?: in PHP? --217.110.53.72 (talk) 10:12, 6 July 2013 (UTC)
thread_title:  Ternary operators 

message: This paragraph is peculiar:
:If both expressions used as conditions are simple boolean variables, it can be faster to evaluate both conditions used in boolean operation at once, as it always requires one calculation cycle, versus one or two cycles used in short-circuit evaluation (depending on the value of the first). The difference in computing efficiency between these two cases depends heavily on compiler and optimizing scheme used. With proper optimizing, they will execute at the same speed, as they will get compiled to identical machine code.
If both expressions are simple boolean variables, then eager and lazy evaluation are semantically identical, so of course a decent compiler will generate the same code for them. In any case, this is an utterly trivial matter. I will remove this paragraph. --Macrakis (talk) 21:17, 4 October 2016 (UTC)
thread_title: Efficiency

message: Bash has two additional operators that act like boolean ones: 
: 
declare out=${foo:-$bar} # out = foo || bar 
declare out=${foo:+$bar} # out = foo  ? bar : ''
            ${out:=$foo} # out = out || foo
            ${foo:?$bar} # if foo is nullish, print $bar value as an error message
The first one is basically a null coalescing operator. I propose to add all of them. Any objections? AXONOV (talk) ⚑ 10:53, 6 February 2022 (UTC)
thread_title:  Additional bash operators 

message: The same as above discussion about Elvis operator. I propose we merge Null coalescing operator and leave redirections in place as there are basically no differences sshort circuit evaluation. Objections? --AXONOV (talk) ⚑ 11:21, 6 February 2022 (UTC)
replies: text: Support as nom per reasons of WP:REDUNDANT. We don't need multiple articles covering the same topic.  --AXONOV (talk) ⚑ 11:21, 6 February 2022 (UTC)

text: No — Short-circuit evaluation covers a principle whereas the Elvis and Null coalescing operators are specific operators. All three deserve an article — GhostInTheMachine talk to me 10:06, 11 February 2022 (UTC)

text: No as per GhostInTheMachine's response, they deserve separate articles rather than a discombobulation of multiple topics in a single article. DevSpenpai::talk 16:35, 28 March 2022 (UTC)

text: Oppose as per my opposition to the other merge, but also because the NCO is specifically, like, a short-circuit OR for nulls. That's the basic difference. I think that difference is enough. After all, XOR is just OR, but, like, not both, and it gets its own article. Ternary operator is basically just an if statement that evaluates to something, and it gets its own article. Plenty of languages have both sc-|| and nco, and the distinction is very important if they have both boolean/falsy types and nulls. I believe it's useful to the reader if we're able to cover them both in-depth, cross-linking as appropriate. Dingolover6969 (talk) 09:22, 23 August 2022 (UTC)
thread_title:  Merge from Null coalescing operator