-1

What was the rationale used for choosing the operators !/&&/|| over not/and/or? Is there some history behind it, or was it just a preference thing?

Some ideas I've had:

  • Rust followed C / C++. However, in the case of for-each loops, the more English-like version of for x in X is used instead of C++'s for (x: X), so Rust didn't just blindly follow C / C++ in everything.

  • The symbols are shorter. The number of characters seems similar between the two.

  • The syntax had to be different due to a collision with type-specifications. There is also difference of a as u8 instead of (u8)a.

Since Rust is a new language, I would think that they could choose either symbols or words without issue. What is the reason Rust chose symbols over words? Why did it not choose both?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
O.O.
  • 828
  • 8
  • 17
  • @Shepmaster and the differences then are due to collisions/confusions with new rust-features I assume? – O.O. Dec 08 '18 at 16:31
  • 2
    I'm not asking for opinions about which is better - rather I'm curious about the history and why choices have been made like they have etc. Might be the answer there is just not very interesting as Shepmaster points out. – O.O. Dec 08 '18 at 16:40
  • @Shepmaster Fair point. I kind skimmed the last paragraph, not realizing that there is this additional question. – Lukas Kalbertodt Dec 08 '18 at 17:18
  • @O.O could you just remove that last question? It's pretty broad anyway. – Lukas Kalbertodt Dec 08 '18 at 17:18
  • 4
    I feel that open-ended "why"s are almost always bad questions because they can lead down a rabbit hole: there's always another "why". Why did Rust use `&&` and `||`? Because of C. Well, *why* did Rust follow C? I guess, because someone thought it was more important to be slightly more familiar to C programmers than to be slightly more English-like. And *why* is it more important? And *why* did C use symbols instead of English-like words, anyway? Etc. As a potential answerer, I'm disinclined to answer because I don't know what answer (if any) will satisfy the asker. – trent Dec 08 '18 at 17:19
  • @LukasKalbertodt Yes, I'll remove the last question; thanks. Wanted to try and preempt what trentcl is talking about a bit with a potential answer - but agree that it is beside the point. Excellent answer btw, thanks alot. – O.O. Dec 08 '18 at 17:42
  • 1
    I don't accuse you of this, but some people also use "why" questions to passively criticize, like "why does Rust not have X" while implying "Rust *ought* to have X" and rejecting any answer as insufficient. This often goes hand in hand with "Rust should add *my* favorite feature". So that's another reason I avoid questions like this. (I did not downvote BTW) – trent Dec 08 '18 at 19:20
  • @LukasKalbertodt "Gosh people, stop downvoting.", first this is not needed you can't ask to other people to stop downvoting, there do what they want. "OP here in that this question can be perfectly answered", yes, every primary oriented question can be answer, the problem is that there is no correct answer. – Stargateur Dec 08 '18 at 20:40
  • @Stargateur Of course people will do what they will; but there is surely reason to ask for constructive comments. How is an explanation to the historic context of the decision and a link to discussion of the feature in rfcs not a correct answer to the question? (How could the question be made more clear to this end - it is what I was after). – O.O. Dec 08 '18 at 21:01
  • @O.O. The problem, whatever how you turn it, your question is asking for opinion. Look lucas answer the first part he talk in the name of "Graydon Hoare", "His goal", "Rust was basically a C++ replacement for Hoare.", "So using the same logical operators as C++ seemed just natural.", "But we are generally opposed to contextual keywords unless absolutely necessary", I don't see what differs `and` from `as`, for exemple, "So the only option was to add alternative operators, but not replace those ones.", "That didn't seem worth it.", all of this is opinion – Stargateur Dec 08 '18 at 21:14
  • @Stargateur Welp, this is turning philosophical - please anyone feel free to edit the question to fit the given answer however you like; it is what I was after. To the point of opinions - it is not an opinion that they were part of the language since early on, or that the rfc to add them was closed. (A why in the more efficient rather than final sense I suppose). – O.O. Dec 08 '18 at 21:35

1 Answers1

6

Back in 2006, Graydon Hoare started working on Rust as a small project. Hoare also worked on the Servo browser engine. His goal for Rust was that it might help with the development said browser engine. Since the engine (like almost all other browser engines) was written in C++ at that time, Rust was basically a C++ replacement for Hoare.

So using the same logical operators as C++ seemed just natural.

When the GitHub repository was created in 2010, && and || were already in the Rust language. See the lazy-and-or.rs test during the second commit in the repository:

if (true && x) { ... }

Over time, the language design process got a lot more democratic and a lot more ideas appeared. But it wasn't until 2016 that someone officially proposed adding not, and and or as an RFC.

But as you can see the RFC was closed. The contributor withoutboats explained it like this:

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.

It is important that at that point !, && and || were already been stabilized for more than a year. So the only option was to add alternative operators, but not replace those ones. That didn't seem worth it.

Disclaimer: I only joined the Rust community in 2014. There might have been larger discussions about this in IRC or other media I can't search. But this is all I could find.

Lukas Kalbertodt
  • 79,749
  • 26
  • 255
  • 305
  • 2
    This answer can be improved. Specifically: *His goal for Rust* - [citation needed]; *basically a C++ replacement for Hoare* - [citation needed]; *seemed just natural* - [opinion]. The second half of the answer is backed up by facts and seems good. – Shepmaster Dec 09 '18 at 16:10
  • 3
    Additionally regarding the difference in `for` loop syntax with C++, note that [rust already had a `for … in …` syntax in 2010](https://github.com/rust-lang/rust/blob/d6b7c96c3eb29b9244ece0c046d3f372ff432d04/src/test/run-pass/foreach-simple.rs) whereas the `for (… : …)` syntax [was only added in C++11](https://en.cppreference.com/w/cpp/language/range-for). – Jmb Dec 10 '18 at 08:19
  • Not sure why this was closed, this answer seems to be backed up by facts – CoffeeTableEspresso Mar 04 '19 at 01:32