Add "not", "and", "or" keywords for logical operations

[real-felix]

Like in some other languages (C python, C++, etc.). I think those lines:

if i > 0 and i < 10 {
    let my_bool = not my_other_bool;
    // ...
}

are more readable than:

if i > 0 && i < 10 {
    let my_bool = !my_other_bool;
    // ...
}

At least, if some people does not agree with me and prefer the second version, let's have the choice about what we want to use.

Please, the debate is not about why those keywords were introduced in C++. It it about the possibility (or not) to introduce them in Rust and talking about advantages and inconvenient.

[KalitaAlexey]

@Boiethios I am not sure with you actually. There are some reasons why there aren't or and and operators in Rust:

• and and or more readable than && and || only to a beginner.
• It forbids to use and and or as variable names.
• Having a choice between either and and or or && and || separates code into two pieces. I think it is actually good that we have no choice about it. Because some people would write and and some would write &&.

[real-felix]

@KalitaAlexey Only the third reason makes sense for me.

• Is it a troll? The readability of a thing mainly depends on the appreciation of the programmer. I use C/C++ at work since many years and I only use the logical operators as words because it is closest to a natural language.
• Did not understand your argument. Yes, every keyword forbid to use the word as a variable, and what ? There is in fact a problem of backward compatibility, but for a version 2.x that is not a problem since a major version can "break" the compatibility.
• C and C++ do it, and that's ok. The question is about what design the rust committee wants.

[KalitaAlexey]

@Boiethios
At first, I mean that I quite good understand && and ||.
At second, this is less priority feature.
At last, So what C and C++ do it? Why can't we don't do that?

[tshepang]

I also find and or more nice on the eyes than && ||. I miss those from Python.

[KalitaAlexey]

@tshepang I miss too, but the main reason I don't want it: Having a choice between either and and or or && and || separates code into two pieces.

[strega-nil]

1. C does not have these keywords. It's a C++ only feature.

2. C++ only has these keywords in order to deal with code written in non-ASCII (i.e. EBCDIC), and we require utf-8, so it isn't a problem for us.

[real-felix]

@ubsan Yes you are right, we must include some header in C to have the macros for and, or, not, etc.

It was at first the reason in C++, but that is not the question here. The fact is some languages have those keywords and that some people prefer writing logical operator in a way closer to natural languages.

[petrochenkov]

C++ only has these keywords in order to deal with code written in non-ASCII

They are used for readability too.
Some data points: https://www.reddit.com/r/cpp/comments/4h5lsb/why_arent_alternative_operators_more_common/

[ticki]

I honestly think that the readability point is dubious. Sigils are easier to scan with your eyes, and especially in logical expression, that become very important, due to the effect on correctness.

[oli-obk]

Sigils are easier to scan with your eyes, and especially in logical expression, that become very important, due to the effect on correctness.

I think that's just a question of editor highlighting.

Even if I sympathize with this feature request, I don't think we should have two identical ways to do the same basic operation.

[real-felix]

I honestly think that the readability point is dubious. Sigils are easier to scan with your eyes, and especially in logical expression, that become very important, due to the effect on correctness.

Come on, every editor put another color for keywords.

[ticki]

@oli-obk @Boiethios Highlighting certainly solve part of the problem, but there is still a problem.

Even with highlighting it is hard to distinguish between not and and.

[Cobrand]

Okay I'm probably going to look grumpy with this message, but I think this idea of adding "or" and "and", and anything else from another language "just because it looks better" is not the right path to follow.

If we are going to start doing this, what is preventing us from adding "elif" and "elseif" as well ? Not only it would be prettier for us to see, but it would allow people from python to not be lost as well. While we're at it, we can also add an optional "then" after the condition of the if, so that people from lua aren't as lost anymore.

We could also add another when declaring variables, where we could say the type between the "let" and the variable name. Easy to detect, if the word right after a let or a let mut is a type, then infer this type automatically. This would get rid of "but I don't like the let var : u32 syntax"-comments from newcomers, since we could add let u32 var = ... to get rid of this problem !

I think people from javascript will be lost too, and tbh "var" is easier to get, any beginner can see that we are declaring a new variable; as such I propose that we use "var" as another alias for "let".

... You get the idea. If we end up adding keywords that are aliases for things that already exist, we're going to have a very confusing language for new starters (and ourselves). Do you really want Rust to become another PHP, where 3 different ways are available for doing one very simple operation ?

Get rid of that frown, I get your point: it's only "and","not" and "or".
But a single and enforcing syntax is still better than multiple alternatives, that's the point I was trying to make. If this RFC gets approved, I don't get why we couldn't approve "TRUE"/"True"/"False"/"FALSE" from entering the Rust language (Raise your hand if you've ever had the error of not having the right "true"/"True"/"TRUE" when switching from a language to another). However practical it may be, it would be bad practice to allow multiple ways of writing a single primitive statement.

I personally prefer "&&" and "||" because they are widely used everywhere (except in Python, eh), not really because they are prettier/uglier/tastier than "and" / "or". But I would have been fine with "and" and "or" if the Rust language had been built like that. As long as there is one enforcing syntax, I would have been fine either way.

[keeperofdakeys]

I think the biggest problem here is that and, or and not are currently not keywords, so before going anywhere, the question is how much code would break.

[withoutboats]

and and or are already used in the standard library as method names. These keywords would therefore need to be contextual, adding significant complexity to the parser. I don't think the complexity of contextual keywords is worthwhile for syntactic sugar, especially a sugar with clear downsides.

[Aatch]

I'm against this. There's no clear advantage that it's worth the disruption. && and || have been standard in programming languages for decades, and arguments from "readability" are pretty weak. There's plenty in the language that isn't "human readable", but we're fine with anyway.

[3442853561]

In my opinion it looks like BASIC.
So why not try to use(counter-example )

fn main() {
    let foo: i32 = 5;
    if not foo==0 then
        println!("No meaning of the sentence");
    endif
}

replace:

fn main() {
    let foo: i32 = 5;
    if foo != 0 {
        println!("No meaning of the sentence");
    }
}

It isn't a good idea, because it will only increase the complexity of the grammar.
And for those already familiar with the syntax programmer is extremely bad experience.
希望我的口胡没有误导你的理解( hope my counter-example doesn't mislead your understanding)

[3442853561]

@Aatch I disagree with " && and ||have been standard in programming languages ", in Visual Basic AND , OR and NOT still be used. But I don't think this suggestion for improvement is good to Rust.

[joshtriplett]

While I personally do like the use of and and or as logical operators, and would have favored such an approach if introduced from the beginning instead of && and ||, I don't think it makes sense to retrofit that into today's Rust. It would require care to avoid conflicting with existing functions named and and or (and care in syntax highlighters to distinguish those), and would create a rift between two different styles of Rust code. Patching existing code to use those keywords would create substantial churn, and not patching existing code would increase total complexity across the ecosystem.

[withoutboats]

I'm going to close this issue.

If I were designing a language from the beginning, I would probably prefer and and or. But we are generally opposed to contextual keywords unless absolutely necessary, contextual keywords in expression contexts are particularly difficult to introduce, and we tend to avoid syntactic sugar of the "pick your poison" variety.

[eonil]

I think ! operator is too small considering its role and importance. But as Rust allows you to put a space between ! and expression, I think it can have enough visibility.

if ! flag { run() }
if flag1 && ! flag2 { run() }
if flag1 && (! flag2) { run() }

Maybe it'd be better to enforce put a space between ! operator and its target expression.

[real-felix]

@eonil I tried to speak about this issue in reddit: https://www.reddit.com/r/rust/comments/8u8o5o/the_not_operator_in_rust/

TL; DR: I use the method instead of the operator and that's fine for me:

use std::ops::Not;

if flag.not() { run() }
if flag1 && flag2.not() { run() }