Support chaining comparison operators in GDScript

[MewPurPur]

What problem am I encountering?

Oftentimes I need two or more comparisons in my conditions, which makes them longer and harder to read.

if my_var1 == my_var2 and my_var1 == my_var3 and my_var1 == my_var4

Having to repeat things multiple times gets annoying with long variable names and expressions. Moreover, if you want to use a function, you have to call it multiple times.
More examples:

if -1 < my_variable_with_a_long_name and my_variable_with_a_long_name < 3
if my_expensive_func(x) > 0 and my_expensive_func(x) < 0.5

How chaining comparison operators would work

Here's how they would improve on the statements above:
my_var1 == my_var2 == my_var3 == my_var4 is True if these variables are all equal.
-1 <= my_variable_with_a_long_name < 3 is True if the variable is in [-1, 3).
0 < my_expensive_func(x) < 0.5 is True if the function returns a value in (0, 0.5). Also, you can avoid calling the function twice without the need to store its value in a variable.

Only adjacent pairs are checked, so if 1 != 2 != 1 were allowed, it would return True.
This feature would, in fact, be compatibility-breaking, as individual comparisons in a chain are currently treated as bools. To get this functionality back, they would need to be surrounded by brackets (which is a good practice anyway)

What to discuss?

I think the biggest point of discussion is how should chaining be allowed.
The comparison operators we have are ==, !=, <=, <, >=, >, in and is.

• We may allow chaining any two comparison operators, and just check the adjacent pairs. Something like x > y != z <= w in [42, 25, 7] would be totally allowed and would mean x > y and y != z and z <= w and w in [42, 25, 7]. And we can only hope no one will actually use it this way.
• We may only allow certain operators to chain. An error would be thrown if operators in a chain are incompatible.
• Perhaps the best property to decide if two operators can be used together in a chain is whether transitivity holds. For example, != wouldn't be allowed because a != b and b != c does not imply a != c and would lead to confusion. With this limitation, the operators that work together would be: <= & <; >= & >; ==; is

Are you in favor or against this idea? Is it worth the time?
Is it worth breaking a bit of compatibility for it?
Would it confuse users?
Does it interact in weird ways with other features?
Could it interact in weird ways with other proposals?
How to implement it?

Can it be worked around?

Chained comparisons can be worked around very easily, but I believe most games would use them quite often, justifying them.

#3595 This is the proposal I closed in favor of starting a discussion.
#889 This proposal discusses ranges, but not comparison chaining as a whole.

[azur-wolve]

Almost any programming language has those problems.
The problem is on the compiler-side-of-the-things (parser and so).

The syntax you have proposed there is a bit cryptic (hard to read, confusing). It could lead to decipher rather than read.

Btw what about that syntax:
[if <expression> <relational_operator> <value> <logic_operator> [optional <relational_operator>] <value>:]

(the optional operator is used if isn't the same of the first comparison)

Examples:

if my_var < (value_1 and value_2): EQUALS if my_var < value_1 and my_var < value_2:

if my_func() (< value_1) or (!= value_2): EQUALS if my_func() < value_1 or my_func() != value_2:

That's a problem also because the parenthesis already have their role.
It looks like that if the existing programming languages haven't solved it yet, is because it isn't viable.
Its better to use good naming and parenthesis for emphasis.

If there's an expensive function, store its returned value in a local variable and then use it for the checks.

Edited:
But talking about compilers, there's also the polish notation. Something like that:
if my_var (<, or !=) value_1, value_2:
The operators are listed first and then the values.
But still hard to read; one of the main problems with polish notation.

[MewPurPur]

As mentioned in the original proposal, Python does actually have this feature with this syntax, and it allows any combination of comparison operators. I don't find it unreadable at all, in fact, I think it's intuitive because it's the same as in math.

The 1st syntax you proposed is quite cool for doing different comparisons with the same variable, but for the more common case of checking if a value is within a range it doesn't look as good. Also, it needs to be expanded into more conditions on chains longer than 3.

[azur-wolve]

My Python knowledge is too scarce; I prefer strong-statically typed & systems languages.

Have reviewed your examples and its true that are not that cryptic.
GDScript should do all the stuff that it could just like Python, as it is a much more mature language.

The only that should not do is the stuff that is custom to the engine, and inconvenient things that don't match well gamedev in Python (slow run-time stuff, etc)

for checking a range → if my_var in (1..9)

[theraot]

C# has a syntax that look similar to what you propose:

if (my_var is (< value_1) and (< value_2))
{
    Console.WriteLine("Yay");   
}

Try it in SharpLab.

[Mickeon]

I'd prefer associating this functionality to some sort of sequence of operators or function.
GDScript aims to be more easily comprehensible and accessible than other languages out there. Chaining operators can easily lead to code that is harder to... read out loud, so to speak.

I'd personally love some way to incorporate a min..max format for range checks. I feel like 0.., -2..5, ..-5 for denoting a range is fairly simple to understand, but there once again may be a problem of clarity, however this could be accomplished.

[filipworksdev]

Python does chaining but many other languages C, C++, JavaScript does not. Is not very common feature . I would favor only a 3 way comparison which is more common than infinite chains.

Kotlin has x in min..max which is x is between min and max. The issue here would be do you do inclusive or non inclusive or a mix of inclusive and not inclusive like range() ?

Using Kotlin's x in min..max min inclusive but max non inclusive would a < b < c which could become a in a..b and b in b..c but > will not work the same way but you can always organize things for one direction only haha 😁

[azur-wolve]

not messed up with Kotlin yet, but the in min..max range thing looks useful in some scenarios
and has good readability

[filipworksdev]

You could also open Pandora's box and rely on a robust operator precedence code that will chain any type of operators like
not a < b + 1 == 3 in [1,2,3] and any issues that arise like adding int with string or boolean with int etc would throw an error at that stage but if it produces a valid result then works and gives you some kind of meaningful answer.

[wareya]

The main issue with comparison chaining is that this syntax is already accepted for bool types:

true < true < false

And chaining comparison operators would also change the meaning of syntax like this:

a < b == c

And making it behave in a different way for non-bool numbers would be inconsistent and make it unclear what a given piece of variable-using code is doing (because gdscript is not statically typed). For python, this kind of situation-specific special case is normal, but for gdscript, it's not.

Lazy arrays and a way to do something like if x in range(a, b): would work. Sugar for ranges like if x in a..b: or if x in a..=b: would also work (for context).

[filipworksdev]

I actually like that x in range(a,b) which reuses already existing logic. And guess what it actually works ex print(x in range(a, b))
But It doesn't really make the a < b < c easier does it? Now that I know this I will be using it.

[wareya]

It works, but it's inefficient, since Godot doesn't have lazy arrays.

[filipworksdev]

I am also thinking you could use two different global functions that can be overloaded with varargs (as many variables as you want)

equal(a, b, c, d, e ...) returns true if a = b = c = d = e .... else false
ordered(a, b, c, d, e ...) returns true if a > b > c > d > e .... else false (if you wanna do less than you list them in reverse)

Might be easier than re-writing the entire GDScript operator switch logic.

At present time you have to manually write these functions anyway so might as well be provided for you if multiple comparison operators will never be implemented.

[programaths]

For ordered we are kind of assuming ascending order in daily life. It's even something we try to break in kids mental schemas as "ordered" has no real meaning without defining the order itself.

As an example, you can order word lexicographicaly, but also by number of letter, or by an hash value or even by how close they are to a chosen word.

A pair of function like between_inclusive and between_exclusive would remove assumptions.
Also: between_inclusive(a,b,c)==between_inclusive(c,b,a)=between_inclusive(min(a,c),b,max(a,c)).

Another option would be "between_xx(a,b,c)". Where xx can be replaced by "o" for open and "c" for closed.
To exemplify:

between_oo(a,b,c) --> b in (a,c)
between_cc(a,b,c) --> b in [a,c]
between_oc(a,b,c) --> b in (a,c] (breaks symmetry)
between_co(a,b,c) --> b in [a,c) (breaks symmetry)

Now, between_xx could throw an exception while between_inclusive and between_exclusive would not.