Rfcs: "Not greater" and "not less" (`!>` and `!<`) operators

[mankinskin]

I have been wondering why these two operators are not supported by most languages. Of course you can achieve the same behavior by using <= or !(x > y). However I would prefer !> over <= even in most cases, because I simply think in terms of not greater rather than less than or equal most of the time. The !(x > y) syntax would require more keystrokes and it reads: not: x is greater than y which is very unlike natural speech and requires the programmer to make a double turn for something very simple.

I am curious why these operators are not widespread, because I can't see how they would make code harder to reason about. Also I don't really see the harm of having multiple syntax for the same behavior (which is an contra-argument that has been made), because I assume syntax should be ergonomic and bend according to the programmer, not the reverse, as much as possible and multiple variants of the same semantics allow the programmer to be expressive in their code (sometimes <= may be easier to think about than !>) and make it easier for the author to communicate what the code is intended for (without comments). Sacrificing a little bit of homogeneity (or whatever) is worth this additional convenience, in my opinion.

I'd like to hear what you think about this feature proposal.

[Ixrec]

My guess as to why they're not widespread is:

• the way we use "not greater" in English is often ambiguous about what should happen if x and y are equal, while it's pretty clear that "greater than" should exclude equality
• The > and ≥ symbols are very common in math, with the obvious ASCII translations > and >=. There is a ≯ symbol, but it's far less common, and !> or >/ seem not quite as obvious or natural.
• As you said, the usual comparison operators >, >=, ==, !=, <, <= already cover everything you might want to do. It's hard to justify introducing a new operator that is "just a duplicate" of one of these.

[mankinskin]

• the way we use "not greater" in English is often ambiguous about what should happen if x and y are equal, while it's pretty clear that "greater than" should exclude equality

I disagree, "not greater" is unambiguous, it means "_anything but greater_" which is also why it is equivalent to "less than or equal". So 3 !> 3 would obviously be true.

• The > and ≥ symbols are very common in math, with the obvious ASCII translations > and >=. There is a ≯ symbol, but it's far less common, and !> or >/ seem not quite as obvious or natural.

That may be true, but to me that is still no reason not to offer convenient syntax. It is an understandable and convenient notation and people could easily get used to it.

• As you said, the usual comparison operators >, >=, ==, !=, <, <= already cover everything you might want to do. It's hard to justify introducing a new operator that is "just a duplicate" of one of these.

Well, it is not "_just_ a duplicate". Is number of keystrokes the only ergonomy we should strive for? We want to code without thinking about it, with as little overhead and with as much expressiveness as possible, and a meaningful syntax helps with that. This feature here may not be very important, I would be fine with using <= as always, but this is not how I imagine the future of programming.

Maybe I should give an example of why I think this is useful. Imagine you have a vector of some objects you are managing and a maximum size you want to support. It is more expressive to write
assert!(items.len() !> MAX_ITEMS, "More than {} items are not supported!", MAX_ITEMS);
than
assert!(items.len() <= MAX_ITEMS, "More than {} items are not supported!", MAX_ITEMS);

The whole point of this line is to ensure that items.len() is not greater than MAX_SIZE. Having the possibility of putting the emphasis on that check is beneficial to understanding the code more quickly. The comparison sticks right out and tells you what its purpose is. You don`t have to think about less or equal and then have to infer that what this actually does is just ensure that the left hand side is not greater than the right hand side.

I think it was a nice idea and would come in handy once one is used to it.

[JuanPotato]

The !(x > y) syntax would require more keystrokes and it reads: not: x is greater than y which is very unlike natural speech and requires the programmer to make a double turn for something very simple.

I don't think rust is very likely to include new operators (or old ones) that exist just for the sake of convenience to save a few keystrokes (see ++ ). Also, I don't think many people get confused when they see !(x > y). If you've been exposed to the syntax for a day you can quickly get used to it and understand it without any confusion. I've never seen the !> operator in any language (besides math), and probably because it's a needless sugar syntax for something that requires two extra characters.

[mankinskin]

We can`t bother being convenient. Syntactic sugar? bleh, who needs that. Math notation? Nonsense!

I don`t see your argument.

[JuanPotato]

Great contribution. I'm saying it makes no sense to add a new comparison that is the exact same as an existing standard.

Adding a new almost identical way to do something to save to characters has no benefit and only serves to add bloat. Pretty sure a common saying is that there should be only one obvious correct way to do something. This addition just makes a new way to write not greater than while there already exists a correct and obvious way

[mankinskin]

Well, its not so much about the keystrokes, more about the meaning of the syntax. I think I get your point that this new operator might lead to people questioning which of the two they should use... but honestly this is a case where that wouldn't happen because both syntax mean exactly the same and both are always valid. It just gives programmers more freedom to make their code as expressive as possible, which is an extremely important part of a language! And in human languages there are different words for the same idea, but they exist because the difference actually matters to the reader/listener. They are interchangeable, but they give color to the sentences.