Short circuit semantic in bool expression

[pmqtt]

Hello folk,
I don't know that short circuit is the reight word for this kind of expression in a if statement:

fn test() -> Bool {
  Print("HALLO WELT");
  return true;
}

fn Main() -> i32 {
   if( (0==1) and ( test() ) {
      // do anything
   }
} 

I think the reight semantic is that "HALLO World" will never printed! But In the current implementation the test function is always called.

[marcauberer]

I am pretty sure, this feature will be implemented eventually as the language aims to achieve the performance of C++ and this would be a considerable optimization path.

As an early adopter, I would not rely on the current implementation, because implementing short-circuiting would cause a behavior change in this regard.

[jonmeow]

Thanks! Filed as #1651

[jmccabe]

Short-circuit semantics should not be implicit.

[marcauberer]

May I ask: why not? I guess you should can always use the single & and | to "disable" the short-circuiting ...

[jmccabe]

Implicit short-circuit forms place a burden on the programmer, and can prevent compiler optimisation. See http://archive.adaic.com/standards/83rat/html/ratl-03-10.html#3.10 for a brief discussion on the rationale behind the addition of explicit short-circuit control forms ('and then' and 'or else') in Ada (from 39 years ago).

Your suggestion of single & etc saddens me; I think that would be bad. Since C++ currently supports the use of 'and', 'or' and 'not', just copy Ada instead of C!

In C++, & is (amongst multiple other things, context dependent, which is something a new language should be moving away from, not retaining) a bitwise numeric operator, not a logical operator (it's the same in Java*). The result is a number derived from the operands so, semantically, it can't be short-circuited. It only works as a non-short-circuit logical form because the result is implicitly (that implicit word again) converted to a Bool which, IMO, remains sub-optimal from a safety, reliability and ease of understanding point of view.

Sadly, it sounds, from what I've read so far, that Carbon wants to retain a lot of the junk that's still in C++ just because it's what people are used to. To me, that is a fundamentally bad idea. It seems to me that those in control of this language 'design' (in quotes, as I haven't seen any obvious sign of a detailed requirement specification that can be designed to) need to really think about what they're trying to do with it, and who is expected to use it. As someone who has been developing software since before Java and Python were created, and seeing the massive churn those went through before bring stable, I suspect Carbon will have the same issues and its likely a good 5-10 years before it reaches anything near maturity, so compromising the language syntax, in particular, by basing around what current developers are used to, rather than thinking about how to make the lives of future developers easy, seems like a retrograde step to me.

Am I right in assuming you've never used Ada?

*I'm being pedantic over the definition of 'logical' here; a 'logical' operator may only take operands with values 'true' and 'false', and returns either 'true' or 'false' as a result. A bitwise numeric operator is like converting each bit of its operands to a 'true' or 'false' value, based on an arbitrary mapping, applying the matching logical operator to those and converting, using a reverse mapping, the logical result back to a bit value of 0 or 1.

[ruler501]

I do think it's reasonable to have non short curcuiting version. I have no idea what that would look like in code though since it'd need a new operator.

[jmccabe]

We're talking about a new language here; it can add whatever operators its authors like!