# What are the downsides of supporting chained comparison operators?

Some languages, such as Python, support chaining comparison operators, such that x < y < z is equivalent to x < y && y < z. This is handy syntactic sugar, and since (x < y) < z (comparing the boolean result of x < y to z) is almost never useful, it would seem to have little cost.

However, many modern languages lack support for this, including Rust, Go, and Kotlin.

What downsides/pitfalls do chained comparison operators have, and/or what justifications do existing languages cite in not including them?

• Related, probably not duplicate: Unambiguous syntax for a ternary comparison operator Jul 2, 2023 at 3:08
• I don't know if this counts as a pitfall, but x < y && y < z isn't quite equivalent because it evaluates y twice. If you do have this feature then you need to ensure that y is evaluated only once. Jul 2, 2023 at 3:30
• @kaya3-supportthestrike Another slight inequivalence is that you'd presumably want to ensure x < z too if you allow arbitrary implementations of comparison operators Jul 2, 2023 at 3:36
• Instead of being syntactic sugar, <, ⩽ and friends could return their RHS wrapped in a type that can be cast to a boolean. Same applies to = and ≠. In fact Goal-Oriented Languages like SNOBOL, Icon and Verse, where first-class success/failure logic replaces boolean logic, work this way and generalise it. Jul 3, 2023 at 14:59

One thing I think Python got wrong in this regard, is that they made this work with too many "comparison operations". Sure, x < y < z is common to write in mathematics, but x < y == z looks kind of weird, and x is y not in z is probably not useful to anybody.

The reason I say Python got this wrong is that empirically, a lot of people are confused about it. Chained comparisons are one of the most recurring Python questions on Stack Overflow; currently, the canonical question has 145 upvotes and 52 duplicates. I think there are even more questions which are indirect duplicates. In almost all of those questions, the user has thought that a OP b OP c must mean either (a OP b) OP c or a OP (b OP c), and been surprised that it means neither; understandably so, because it would be true for all other operators.

What could Python do differently? I think chained comparisons like x <= y < z make the most sense when the two comparisons are both inequalities in the same direction, either both < or <=, or both > or >=. Other comparison operators like ==, !=, in, not in, is and is not should not get this treatment.

On the other hand, if chained comparisons are limited this way then most use-cases could be served instead by testing membership in a range or interval, e.g. y in range(x, z). So, if you have suitable types in your standard library for representing intervals, then you might not need comparison chains at all. This still leaves longer chains like x < y < z < w, and cases where computing z might be expensive so you want to skip computing it when x < y is false; but these are edge-cases, so I wouldn't worry too much about them as a language designer.

This doesn't mean that x < y < z should mean (x < y) < z instead; as you mention, that's generally useless. My approach in my language MJr is to make this expression a syntax error: the comparison operators are neither left- nor right-associative. This requires no special treatment in the parser ─ just treat both operands like you treat the right operand of a left-associative operator or the left operand of a right-associative one ─ but I did decide to add a specific error message to say that chained comparisons are not supported.

• I disagree when you say that ==/is should be excluded. Sometimes, it can be useful to check that a = b = c, and I don’t like having to arbitrarily choose between a = b AND b = c vs a = b AND a = c. (I’ve heard that in some SQL implementations, which pairs you choose can drastically affect performance.) Jul 2, 2023 at 3:32
• @Bbrk24 The problem is that beginners often write x < y is True or x < y == True, which would be correct if it meant (x < y) is True, but it doesn't. Jul 2, 2023 at 3:34
• Then just make it its own group, the same way you suggest separating < from >. Jul 2, 2023 at 3:36
• @Bbrk24 You could, but you would have the same problem with x == y is True, or x in y in z where z is a list of booleans (yes, I have seen someone write that and wonder why it didn't work). The case for x == y == z is strongest, but personally I don't find anything wrong with x == y and y == z; or you can write len({x, y, z}) == 1. Jul 2, 2023 at 3:38
• y in range(x, z) is okay, but it lacks the syntactic clarity of x<=y<z and immediately becomes fiddly and ugly if you want x < y <= z or whichever variant isn't immediately covered by whether the particularly implementation of range is open, closed, or half-open. Jul 2, 2023 at 11:28

Generally speaking, I'd say it's always best if a feature is first class instead of ad-hoc. It's easy to have first-class (2-arg.-infix) comparison operators, but chained comparison operators can only be done as an ad-hoc rules in most languages.

What I mean here is, a normal < operator is simply a function with type (Int,Int) -> Bool (or some polymorphic version of this) and some infix precedence. None of this really requires special parser handling: infix operators are pretty much universal because (unless you're a Lisper) you certainly want + and * with the normal precedences.

That means it is also fairly obvious how these operators should be overloaded or passed to higher-order functions (as long as you know how that is generally done in your language). It's not impossible to do that kind of thing with chained operators, either, but it's certainly a lot less obvious what's actually going on. The way Python does it is quite ad-hoc, in that it desugars the chain of comparisons to binary calls to __lt__ connected with and operators. Why use those in particular? What if somebody would like to use this with another type instead of bool? It gets all very confusing.

You might argue that the special case of simple boolean-valued comparisons is important, "canonical" enough to warrant special-case handling. Perhaps it is, but it's always best to make do without special cases.

I'd remark that there is at least one language that supports chained comparison "naturally", without a special syntax rule: in Verse, there is no boolean type at all. Instead, comparison operators either succeed or fail, which are concepts the language has hard-baked, and having a chained comparison simply means you twice compare and each time it might fail.

The language designers themselves aren't quite sure whether that's just a cute quirk of the language, or actually a good feature...

Another thing I'd claim is that chained comparison are pretty much useful for only one thing: testing whether a number is within an interval. Sure that's a fairly common thing to do, but wouldn't it be better to extract that general concept? You just need an operator ∈ (or some ASCII rendition) which checks whether a variable is inside some set-like thing and a suitable class of set-like things including ranges (which for example Python does in fact already have).

• python's b in range(a, c) is only equivalent to a < b < c if a,b,c are all integers, though. There is no continuous range for floats. Module sympy does have an Interval type but it's heavy artillery.
– Stef
Jul 2, 2023 at 18:46
• @Stef well, Python has chained comparison and uses range mosly for looping. My point was that if a language really wanted to support interval checks in a nice way, it could easily do that without chained comparisons. Jul 2, 2023 at 18:50
• Isn't a bool just "succeed or fail"? I can't see any advantage whatsoever to allowing comparison operators to return non-bools Jul 2, 2023 at 19:12
• @RydwolfPrograms a bool is just a type with two values. What meaning is assigned to these values depends; often true is actually the failure-ish case (e.g. classical 0 = exit_success). Also, whether you like it or not, comparison operators can and do often return things other than booleans. For example in Matlab and Numpy, comparisons of arrays/matrices give a mask as the result. In proof assistants, comparison operators may yield a Prop rather than a Bool. Etc. etc.. Jul 2, 2023 at 20:28
• speaking of Lisp, comparison functions are variadic (< 3), (< 3 4), (< 3 4 8 7) so it is quite natural too Jul 13, 2023 at 11:44

In an imperative programming language, the operational semantics of n-ary comparison operators are tricky.

Say we have a < b < c, where a, b and c are expressions that may cause side effects. If we have a < b, it's easy: evaluate a, evaluate b, and then see if the value of a is less than that of b. More formally, we write: if $$\Delta \vdash a \Downarrow v; \Delta'$$ and $$\Delta' \vdash b \Downarrow v'; \Delta''$$ , then $$\Delta \vdash a < b \Downarrow \mathtt{is\_true}(v < v'); \Delta''$$.

This is what we call big-step operational semantics. $$\Delta$$ is just a store that maps variables to their values, and $$\Delta \vdash e \Downarrow v; \Delta'$$ here means that evaluating $$e$$ under the store $$\Delta$$ produces the value $$v$$ and a (possibly modified) store $$\Delta'$$. So this is clear to most of us, and is what most of us would expect when we enter a < b.

But when we have n-way comparisons, this becomes tricky. In what order are the expressions evaluated, and at what time do we compare them? If expressions may produce side effects, then this will affect the result of the comparison as well as the store environment after evaluation. Both of the following options seem quite reasonable for a < b < c:

• evaluate a, evaluate b, evaluate c, then perform value checks;
• as syntactic sugar for a < b && b < c, which means b will be evaluated twice, possibly in different environments.

I'm sure you can come up with others. Unless you have a very well-defined operational semantics, this will just cause confusion everywhere.

However, if you are working in a pure programming language without any side effects, the order of evaluation cannot affect an expression's value, so semantically this is pretty safe. Some people will argue that this will create problems with parsing/surface syntax, but as long as we have a well-defined semantics, surface syntax is just a matter of taste.

Boolean equality is XNOR. I have (ab)used this before; a language which allows a == b == c would not be able to exploit this.

• != is XOR on Booleans, too. Jul 2, 2023 at 3:54
• You would still be able to do this right? You just need parens: (a == b) == c Jul 2, 2023 at 4:04

My inclination would be to have a comparison operator for type T yield a comparisonResult(T) which encapsulated a Boolean and a T, and have a comparison operator overload which accepts a comparisonResult(T) and an operationYielding(T). For efficiency, operationYielding(T) should be a compiler-internal type distinct from functionReturning(T); functions accepting arguments of that type would generally have their code folded into the calling context in such a way as to avoid having to create any kind of closure object to access automatic objects in the parent context.

• Does this mean that let b = x > y; would have b be some type other than Boolean? Or would this be contextual? Jul 2, 2023 at 16:21
• @kaya3-supportthestrike: Interesting question. If Boolean types were not allowed to use comparison operators, then any use of b would either unambiguously require that the type coersion be performed (and its timing would be irrelevant), or that it not be performed (rendering the timing moot). I think I'd handle the situation by specifying that let c = b > z would only be allowed when z was known to be a type that couldn't be compared to a Boolean but could be compared to y, and a compiler had kept the earlier ComparisonResult. If code wanted to chain a comparison using b, ... Jul 2, 2023 at 16:47
• ...it would need to be written as something like let c = cast(ComparisonResult(typeof y,b)(b) > z, which would be rejected unless b was already that type, or as cast(bool,b) > z. I subscribe to the idea that having compilers reject constructs whose intended meaning is ambiguous in the absence of directives that would set default behaviors, is better than having language designers try to guess what such constructs should mean. Incidentally, I'd also (absent config directives) reject e.g. double1 = float1*float2; requiring either double1 = (double)(float)(float1*float2); or... Jul 2, 2023 at 16:53
• ...double1 = (double)float1*float2;. Even if language rules were clear about how a compiler woudl interpret the original construt, and a human reading the code would have no trouble knowing how a compiler would interpret it, a human reading the code would often have no way of knowing how the programmer who wrote the code was intending that it be processed. I'd regard the latter forms as superior to the former if the program cares about which method is chosen, and if a programmer wants "whichever is faster" semantics, there should be a way to indicate that. Jul 2, 2023 at 16:56

For what it's worth, modern C# allows this syntax as part of its pattern matching features:

public static bool IsLetterOrSeparator(this char c) =>
c is (>= 'a' and <= 'z') or (>= 'A' and <= 'Z') or '.' or ',';


That's an extension method (signified by the this keyword) that extends the char type. It returns true if c is between 'a' and 'z' or between 'A' and 'Z' or a period or a comma. Personally, I think it's more readable than the "chained operators" discussed here.

Coming from a C family background (C, C++ and C# - a touch of Java), I'd read x < y < z < w as ((x < y) < z) < w which makes no sense to my eyes.

One quirky problem with chained comparisons is that they are deceptively difficult to implement (easy to implement approximately, but difficult to implement exactly). It might seem to you that you can simply rewrite a < b < c as a < b and b < c, but that's not the case: what if b is a function with side-effects? The generated assembly code would call it twice instead of once.

That problem might seem similar to the problem which occurs when compiling += and similar operators, when incrementing an element of an array with the index being a function with side-effects, but that's actually not the same problem. There doesn't seem to be such a simple solution (of using a local temporary variable) to the problem with chained comparisons.

• What do you mean by "There doesn't seem to be such a simple solution (of using a local temporary variable) to the problem with chained comparisons."? Of course you can use a temporary local variable to reuse the result of b. Why not? Apr 29 at 17:43