expand on range & "inverse" range checking

[MaliusArth]

Odin currently supports range checking via comparison operators:

range :: struct { min, max: f64 }

if x >= range.min && x >= range.max {}
if x <= range.min || x >= range.max {}

Unfortunately, this syntax makes it hard to identify errors and intent.
For example, did you recognize the typo in one of the comparisons?

This method of range checks can be made clearer using "yoda" expressions

if range.min <= x && x <= range.max {}
if x <= range.min || range.max <= x {}

While this slightly improves readability and intent, it can definitely be improved upon.

Odin already has range operators which significantly improve readability & intent signaling while also reducing surface area for errors.
As of now, though, their use for range checking is quite limited:

switch x {
case range.min ..= range.max:               //   supported

case !(t_range.min ..= t_range.max):        // unsupported
case not_in t_range.min ..= t_range.max:    // unsupported
}

for x in range.min ..= range.max {}         // range loop
for x not_in t_range.min ..= t_range.max {} // unsupported
for (x in map) {}                           // condition-only for-loop
for (x in range.min ..= range.max) {}       // unsupported

if x in range.min ..= range.max {}          // unsupported
if x not_in range.min ..= range.max {}      // unsupported

The if statement variants probably offer the most bang for the buck as they don't seem to collide with existing language constructs and can be combined with regular loops. Furthermore, the already supported switch variant can work around the ambiguity of the for statements.

As for range exclusion checking, ie. checking whether a variable value resides outside of a range, no support exists in any of the currently existing control flow statements.

To sum it up:
At the very least add support for range checking via range operators in if statements

if x in range.min ..= range.max {}
if x not_in range.min ..= range.max {}

For completeness & consistency it would be great to support range operations in all control flow statements.

[gingerBill]

None of this is ever going to happen.

For this to work, ranges would have to be a moveable construct rather than mere syntactic sugar. And some of those things don't make zero sense, especially for x not_in ... based loops.