What alternatives are there for C/C++ assignment operator (=) and equality operators (==) syntax?

Question

C/C++ use = for assignment and == for equality comparision. For example, a snippet in C++ can be like this:

int nuclear_code; 
nuclear_code = 1111; // assign nuclear_code  with the value 1111

if(nuclear_code == 1234) 
/* compare nuclear_code with the value 1234
** This will return false because 1111 != 1234
*/
{
    // This will never be executed.
    std::cout << "Nuclear fired!"; 
}

But this can lead to unwanted bugs when programmers accidentally make a typo. Consider this example:

int nuclear_code = 1111; 
if(nuclear_code = 1234) 
/* Oops, instead of ==, this is = now!
** This will assign nuclear_code with the value 1234
** and it will return the lvalue referring to the left-hand operand, which is 1234
** This is now true.
*/
{
    // This code will be run.
    std::cout << "Nuclear fired!"; 
}

This is a (very) common typo in C/C++, partly because the two operators are so similar.

So what are the alternatives?

Answer 1

Just throw Unicode symbols at it (the APL way)

APL uses ← for assignment and =/≡ for equality (= is term-wise, ≡ is for the whole array). If you can afford to just throw Unicode at the problem, sometimes it's a fun solution :) really depends on how the language is meant to be written, though.

Answer 2

Distinguish Assignment and Equality by Context

Some languages use = for both assignment and equality. The way the language differentiates the two use cases is by constraining the grammar so it's obvious which context is meant.

For instance, in BASIC, there is no such thing as an "expression statement", so if you write something like x=1 on a line by itself, the only possible interpretation is that you are assigning 1 to x. The alternative interpretation of "check if x is equal to 1 and discard the result" isn't an allowed interpretation in the language. This is in contrast to a language like C where both interpretations are legal (and thus, the compiler needs an additional symbol to disambiguate the two interpretations). Some languages also use a keyword like let or set to begin an assignment statement which can also help distinguish the two.

The advantage of having only one operator for both operations is that it simplifies the language. It also means that the compiler will never misinterpret your program because of a careless error. On the other hand, it is less expressive than languages that separate out the two operations. For instance, in C++, you can assign to variables within a condition or loop. In a language like BASIC, you cannot do this which may lead to more verbose code in some cases.

Answer 3

Even though the OP sepcifically asks for different syntax to prevent this kind of error, I would make the case that a better approach is a semantic solution:

The reason why this error can occur in C++ (and in C for that matter) is that an assignment expression evaluates to a reference to the assigned variable (int& in this case) and that int is implicitly convertible to bool (*). By changing either of these properties we can prevent this error.

---

If we forbid implicit narrowing conversions or just the implicit int -> bool conversion we are already fine. This however prevents the following common C idiom:

int status = my_api_call(/* ... */);
if (status) { /* Handle error */ }

But I would argue that this alternative code is easier to understand and just as simple to write:

int status = my_api_call(/* ... */);
if (status != 0) { /* Handle error */ }

---

If we evaluate assignment expressions not to a reference to the assigned value but to void we also solve the problem, but this time we prevent this idiom:

a = b = c; // Assign the value of c to a and b

However this is rarely used and confusing if not seen before, and the alternative

a = c;
b = c;

is not significantly more verbose (and much clearer), so I would argue that losing this idiom is also not much of a loss if not an improvement.

---

So in conclusion I argue that while either of the approaches solves the problem, both of them are reasonable in their on right and can prevent other possible code smells.

Also now you are free to choose whatever syntax you like without the restriction of having to solve this problem.

(*) On top of that, in clauses of if statements, also explicit conversions to bool are considered in C++. This rule exists so class authors can make conversions to bool explicit, which prevents implicit conversions from the custom type to integral types (via class X -> bool -> int) while still allowing the class to be used as a condition in if statements, but in our case it makes matters worse.

Answer 4

The Pascal way

i.e using := for assignment and = for equality check.

The example in the question can be written in Pascal as:

program Hello;
var nuclear_code : integer;
begin
  nuclear_code := 1111;
  if(nuclear_code = 1234) then writeln('Nuclear fired!');
end.

This is so harder to mistype the two.

Answer 5

The GNU solution to the if(x = y) {} problem is to require double parenthesisation where only if((x = y)) {} is unambiguous.
That said, to mean assignment, the =, :=, <- and ← operators are common across many languages descending from C, Pascal and BASIC.
Vale uses a set keyword to mean reassignment.

In languages where the concept of "(re)assignment" does not exist, like most Functional and Logical ones, it is not uncommon to see = be used both for bindings and as the equality binary operator, along with ==.
For instance, in a language lacking builtin mutation support, this code is unambiguous:

main =
    let x = 42 in
    putStrLn (if x = 42 then "h" else "Ü")

Some English-oriented languages, like CoffeeScript, also use a is keyword.

For completeness, are also common as inequality operators !=, /=, <>, ≠ and isnt, all used in various languages.

Answer 6

Common Lisp

Most of the time when you need a variable, you'll use let.

(let ((x 10))
    ;; Now I can use x in this scope, and it has a value of 10
    ...)

There's also setf.

(setf *x* 10)

Equality checking looks like one of the following (depending on what exactly you want—there are more equality operators).

(= x 10)
(eql x 10)
(equalp x 10)

It's really hard to accidentally mix the two up.

Answer 7

Use <-.

using <- for assignment and = for equality check.

Like this:

a <- 5
b <- 5

if a = b:
    . . .

PS: like APL, but not UNICODE.

Answer 8

Use :, like JSON

Assignment and comparison have different purposes, return values, and allowed syntactic locations. Therefore, they should be represented with bigger differences than a single extra character.

The use of : for "assignments" is already fairly common and should be familiar to users:

• JSON/object notation: uses colon to bind a value to a key.
• English: like this list, where a colon associates a value or comment with an entry.

This gives you a one-character solution for assignment, leaves = free for equality, and should be immediately clear to readers.

Answer 9

It partly depends on the semantics of variables and the semantics of equality.

Some languages distinguish between intensional and extensional equality. One example of this might be a set of integers represented as a binary search tree. Two sets are intensionally equal if the trees have the same structure, but extensionally equal if the numbers in the sets are the same.

Yet other languages have different notions of equality testing that depends on whether or not they will coerce types. Does 3 == 3.0 in a dynamically typed language? Sometimes you want that and sometimes you don't.

Other languages have object identity, which is different from equality.

This is a lot of symbols for equality testing that you might need to invent! Common Lisp has four of them.

Logic languages have only one symbol =, and it means unification. Just looking at simple values like numbers for the moment, if you type X = Y, then it can mean several things:

• If X is a free variable but Y has a value already bound to it, this assigns that value to X.
• Same thing if Y is free but X is bound; this is left-assignment.
• If X and Y are both bound, then this is an equality test.
• If X and Y are both free, then this aliases the two variables together. A subsequent binding of X will automagically also bind Y.

In general, X and Y could be data structures with some bound and some unbound variables inside it, in which case the full unification algorithm is run.

Answer 10

In Assembly (mov) or more basic languages there is a keyword for assignment, such as:

set X to 10

I am personally not a fan of this because I prefer punctuation as operators, but this is an option that resolves ambiguity.

Or in Assembly:

mov rdi rax

Answer 11

Different Spellings

Other common variations for assignment are := and (so far unmentioned) <-. JavaScript is notorious for having many different comparison operators.

Vale has the interesting variation that x = 42 is only a variable declaration, and assignment must be written set x = 42. I find, like the author, that I also write many more dclarations than assignments.

Different Semantics

A functional language, using static single assignments, or one using linear types, allows assignment only within bindings, which can be marked with let. Alternatively, since newer languages tend to discourage mutability and assignments, you could mark assignments with set, or do both. Since is is no longer than == and be or to no longer than := or <-, this could be valid syntax:

let there be light
if there is light then
    set heavens to waters.above
    set seas to waters.below

Answer 12

Modern programming languages like Go use the "="/":=" for assignment and "==" for the comparison. It gives a compile time error if you mistype "=" instead of "==". Another suggestion would be to use constants when comparing, but that wouldn't solve your problem with mistyping in C++.

Answer 13

Coming relatively out of left field is Swift’s pattern-matching operator ~=. It’s rarely written in source, instead the result of desugaring a switch or if case statement, but you could use it instead of == for regular equality comparison if you wanted to.

Answer 14

smalltalk

The original Smalltalk uses ← for assignment and = for equality. It also uses ↑ for return.

The original Smalltalk developed at Xerox used its own workstation developed at Xerox with its own CPU developed at Xerox and its own input devices (keyboard and mouse) developed at Xerox. Smalltalk was its own Operating System as well.

All this to say that it also had its own character set and character encoding.

When Smalltalk first was ported to other systems using the ASCII character encoding, it turned out that ASCII had the character ^ at the same code point where Smalltalk had ↑, so all Smalltalk was rendered with ^ for return on machines that used ASCII. It still looks like an upwards arrow, so it still kind of works.

Assignment was not so lucky, though: where Smalltalk had ←, ASCII has _, so all assignments in Smalltalk were rendered as _ in ASCII. This was somewhat unsatisfactory, so it was decided to change the language specification use := for assignment. However, some Smalltalks still accept _ even today.

Answer 15

Use ,= or ;=

We could already understand ,= as the +=-like version of , in C-style operators. And ;= looks less confusing, if you already merge , with ;.

Answer 16

Most compiler have the decency to give you a warning if you use the wrong operator, or if the compiler isn't sure. For example, with a good C compiler I expect that

if (nuclear_code = 1234) ...

gives a warning. And if I really want to store 1234 and then examine whether it is zero, these compilers may allow

if ((nuclear_code = 1234))

which tells the compiler "be quiet, I know what I'm doing".

Newer languages don't allow integers to be used as boolean values. So the first example might not compile if the = operator doesn't yield a result, or it yields an integer result which cannot be used in an "if" statement. That's assuming that

if (condition = false)

would be very rare.

You could use different pairs of tokens. := and =, or = and .eq. like FORTRAN did, or a leftarrow for assignment. The warning, and possible changed semantics, is the simplest solution. In the end, if the code you type is not the code you wanted, that's your problem.

Answer 17

You can raise an error

For example this code in Python is correct:

a = 11

if a == 22:
    print("Something")

But this:

a = 11

if a = 22:
    print("Something")

raise an error (no confusing bug like C++):

  File "somefile.py", line 3
    if a = 22:
       ^^^^^^
SyntaxError: invalid syntax. Maybe you meant '==' or ':=' instead of '='?