Proposal: chaining equality/inequality operators

[Tyrrrz]

Motivation

In math, ranges are very often specified by chaining multiple inequality operators, like so:
5 <= x < 9 or 0 < a <= b < 3
When working with code that deals with numbers, you often end up having to either check equality of multiple variables or check whether they're contained in a certain range. Normally you just write long conditional statements like these:
if (a == b && b == c && c == d) { }
if (a >= 5 && a <= 10) { }
Of course, to improve readability, you can write your own helper methods:
if (AllEqual(a, b, c, d)) { }
if (a.InRange(5, 10)) { }

Proposal

Allow chaining comparison operators:
if (a == b == c == d) { } (instead of if (a == b && b == c && c == d) { })
if (5 <= a <= 10) { } (instead of if (a >= 5 && a <= 10) { })

[Unknown6656]

Forgive me if I am wrong, but isn't a == b == c == d already a valid syntax, which will be interpreted as ((a == b) == c) == d?
This could create a confusion, because the expression would be true if a = false, b = false, c = true, d = true . Of course, you are talking about numbers, but this would still break existing code .....
And what would happen, if one defines a type, which implicitly casts to bool and use it in a chained expression?

[orthoxerox]

IMO this is too much work for too little benefit. How would you parse a <= b <= c? What if I actually have an operator==(bool left, C right)?

[Tyrrrz]

@Unknown6656

Forgive me if I am wrong, but isn't a == b == c == d already a valid syntax, which will be interpreted as ((a == b) == c) == d?

In ((a == b) == c) == d, a == b evaluates to bool and is then compared to c. It works only if a,b,c,d are all of boolean type. Also, as you correctly noted later, these statements are not equivalent.

And what would happen, if one defines a type, which implicitly casts to bool and use it in a chained expression?

As with any other instance of implicit casting, the most specific variant will be used.

[alexpolozov]

@Tyrrrz this means that to preserve backward compatibility, chaining equality cannot be implemented for bool, only for all other types. Otherwise, this code would change meaning:

bool canRead1 = CheckPermissions(user1, file);
bool canRead2 = CheckPermissions(user2, file);
if (canRead1 == canRead2 == Settings.PermissionsShouldMatch) { ... }

Implementing a syntactic form for all types that allow == except one would be a bit weird and inconsistent in C#.

Chaining inequality is a good proposal, though.

[dmitriyse]

Probably some parenthesis required to enable math-like expression:

if ([[ a < b <c ]]) { ... }

And other operators should not be allowed in this expression, otherwise

if ([[ a< b && b > c ]]) 

even if good will always too "brain bending" and error prone.

Anyway this feature have too little benefit for required efforts.

[phi1010]

@apskim: We can overload operators... "==" does not need to return a boolean, we can also return other data types, e.g. three-state-booleans, as long as both "==" and "!=" return the same type. I think this also applies to inequality.

Especially when using multiple state logic ("false", "maybe", "true"), those three comparisons may return different results, and all be syntactically valid:

(a < b) < c
a < (b < c)
(a < b) && (b < c)

[ufcpp]

https://gist.github.com/ufcpp/3509ba373ab1622ac9b77e78dea26ecc

[lachbaer]

Seems to be rather a case for a NuGet package or .NET framework proposal. You cannot expect to replicate @ufcpp 's fine code every time you need it in one place 😉

[aaronfranke]

The problem in OP is certainly valid, but is there any proposed language feature that can actually make the situation better, without breaking existing projects, and without more complicated syntax than just writing out all of the comparisons combined with &&?

Are there other languages that can handle chaining comparison operators like this?

[absurdlylongusername]

Python handles transitive comparison operators, like chaining <

[quinmars]

With and and relational patterns that could look like:

if (a is >= 5 and <= 10)

see the following comment in #2115

[TahirAhmadov]

I am also frequently annoyed by the 1 < x < 5 type conditions, but given existing syntax, and other constraints, sadly it'll probably not change. I would recommend 1 < x && x < 5 - yes, the x && x in the middle is not ideal, but it follows the general syntax, is still very readable, and does not introduce a conflict into the language just for the sake of these math comparisons.

[333fred]

See #4108.

[CyrusNajmabadi]

sadly it'll probably not change.

I am championing a proposal on allowing this to change :D

[TahirAhmadov]

Oh great, I didn't even know about that.