Keywords like `is`, `or`, `isnt`, instead of `==`, `!=` and `||`

[Neutron3529]

@Uther

let a = b & &c;
let x = || y || z;
let n = ! m!(o);

I'd rather wrote:

let a = b & (&c);
let x = ||{ y || z };
let n = m!(o).not();

[KSXGitHub]

Python doesn't have isnt. Instead, it has is, not, and is not.

[KSXGitHub]

I understand your frustration. But I don't agree with your argument. The standard library (core, std) as well as the crates in the Rust ecosystem (crates.io) already use English names exclusively. Having to read a few more English words add no significant language barrier.

Perhaps one day, when Western influence finally wanes, there shall be an effort to make a programming language that is perfectly localizable. But I don't expect that day to be in my lifetime.

[yigal100]

Code isn't prose but rather a form of technical writing and as such should be using well established notation that is the norm in the field. Really, any written text would be most readable and appropriately concise when it uses the relevant jargon and notation as establish in the field of that particular audience. It would be very cumbersome for example to present a mathematical proof to one's math peers with an artificial constraint of only using plain English.

Rust's choice of syntax here very much follows that practice - these operators are understood by programmers ubiquitously as it is the established notation in the field. In other words, it doesn't matter if I'm programming in PHP, or Java, or C++, or Rust (or Bash, or.. you get the point) all of them will have these same operators with the same semantics since programming has converged to this nearly universal notation over the years.

Yes, there are still a few exceptions but overall this is the accepted standard notation. Diverging from this by having English words would actually reduce readability since it would raise questions about the semantics of the new keywords.

[nop_thread]

No, I don't want to avoid English identifiers. In fact I prefer English names to arbitrary names written in non-ASCII Unicode (including my native language). I'll never name my variables and functions in my native language since it prevents almost all people over the world from reading my code. (But this is another topic...)

The root cause of my frustration is that, some kind of English-like keywords makes it hard to distinguish names and non-names. In !foo && bar == baz, three names are delimited by obviously (yes, obviously to me the non-English speaker) non-identifier tokens. This helps me a lot to parse the expression quickly.

In contrast not foo and bar is baz is not. The most important point is, keywords looks too similar to names in such expressions in this form.

From this viewpoint, I like the convension used among people writing SQL: write the keywords in capital, symbols in lowercase, as SELECT col1 AS newname FROM table1 WHERE col3 IS col4 AND cond1. Still I don't feel comfortable, but much better than select col1 as newname from ... and acceptable.

Back to the original context: NOT foo AND bar IS baz feels less confusing to me than lowercase keywords, but not foo and bar is baz is too confusing. Even if I can ignore operator precedence, foo and bar and baz and qux is hard enough to read.

[robinm]

In a black and white environment, I totally agree. But with syntax coloration, all keywords have a different color than names, and thus easy to distinguish, so I’m a bit surprised that using symbols is still a plus for you.

[nacaclanga]

Given that Rust uses UTF-8 I see only two benefits of replacing operator symbols by strings.

a) The symbols &, |, ^ and && and || for bitwise and logical operators are not nearly as universal like + or - etc and string like names are allready in use for the corresponding traits.

b) Some of the symbols #, @, ~, ^, \, `, |, [, ], { and } are found in less accessable location on quite a few keybord layouts, thus avoiding them makes it slightly easier to type.

What I in particular do not see, is a good reason to replace == or != by is and isnt. These symbols are easily accessible on all keybord layouts I am aware of and their corresponding trait is called Eq. And in fact the is doesn't fit very well in the meanining of an (un)equality operator.

Be aware that C++ (which defines the aliases mainly for encoding reasons) also doesn't define an alias for == and calls != not_eq rather them isnt.