Go can be a bit verbose, but that's often for the sake of keeping the language simpler to learn and understand. I worry that this change would save you a few keystrokes in some very specific cases, but at the cost of making the code significantly less readable - especially because there's no precedent in other languages with this syntax.

This seems like an extremely specific feature. It is only useful if you have several variables that you want to compare to the same other thing and AND all the comparisons together. You can't OR them, you can't check them against different values, and if you ever decide that you need something more complicated, you'll have to rewrite the entire thing.

I agree that it simplifies that specific case a bit, but it doesn't seem particularly orthogonal.

You can't OR them, you can't check them against different values, and if you ever decide that you need something more complicated, you'll have to rewrite the entire thing.

You can use AND instead of OR, example:

OR:

if i <= 0 || j <= 0 || k <= 0 {
   return
}

Equivalent AND:

if !(i > 0 && j > 0 && k > 0) {
   return
}

Proposed equivalent:

if !([i, j, k] > 0) {
	return
}

See also #33694 for another proposed change that combines comparisons.

In Go as in some other languages the && operator short-circuits: if the left expression is false, the right expression is not evaluated. With this syntax, what happens with (f1(), f2(), f3()) > 0?

In Go as in some other languages the && operator short-circuits: if the left expression is false, the right expression is not evaluated. With this syntax, what happens with (f1(), f2(), f3()) > 0?

It would be evaluted as f1() > 0 && f2() > 0 && f3 > 0, so it also short circuits.

Thanks. I don't know how else this could be implemented, but it seems potentially surprising that in a list of function calls only some of the calls are executed.

I find none of the rewrites clearer than the original. The syntax is shorter but much less clear. There's no intuition, for instance, about whether (i, j) < 0 means i < 0&& j < 0 or i < 0 || j < 0. It gets harder to decode as the expressions grow.

I'm closing this for now as this design doesn't seem to get much support.