if (arr<:0:> not_eq 0 and not false)

This line of code is actually C++. I recently noticed a small section called Alternative tokens in the standard (it’s 2.6, for the curious) which allows this sort of shenanigans.

The following code will probably look slightly alien to you, like a weird C++ knockoff, but it’s a standard conforming C++ program:

%:include <iostream>

using namespace std;

int main()
<%
        int arr<:2:> = <% 1, 1 %>;

        if (arr<:0:> not_eq 0 and not false)
                cout << "Hey, this works!" << endl;
        return 0;
%>

This program is compiled happily by GCC and Clang. Visual Studio 2010 allows this code when it’s compiled with /Za. Without /Za, it’s still possible to use the alternative operators (but not the digraphs) in Visual Studio by including <iso646.h> (thanks to Vasily Milanich for pointing it out to me).

The C++ standard provides a set of alternative tokens for some operators and other symbols. Here is the complete list:

PrimaryAlternativePrimaryAlternative
{<%&bitand
}%>|bitor
[<:^xor
]:>~compl
#%:&=and_eq
##%:%:|=or_eq
&&and!=not_eq
||or^=xor_eq
!not

According to http://www.lysator.liu.se/c/na1.html (thanks to Matt Healy for finding the page), these tokens are the result of a “Danish proposal” to make C programs more visually appealing on terminals that only offered the 7-bit ISO 646 character set which didn’t have curly braces, for example.

The advantages of using the alternative tokens are that they might make code look more appealing to curly brace haters, and the alternative logical operators will make Python programmers feel more at home. They will also come in handy for a code obfuscation contest.

The disadvantages probably include a lot of WTF comments from other C++ developers.

Jokes aside, I haven’t seen any of these in real world code. A few people on r/cpp said they use or advocate them, however.

This made me wonder if the alternative operator tokens can or should be used more widely (I’m pretty sure using the digraph alternatives for curly braces etc. isn’t a good idea). In particular, not, and and or are readable, obvious and not verbose.

For anyone who sees the alternative operators for the first time, I think there’ll be quite a lot of confusion, followed by trying to figure out how they work. I’m not sure people will immediately check the standard, so they might waste some time on investigation, e.g. if they decide the operators work via preprocessor magic within the code base.

After the initial confusion though, it’s really obvious what the alternative operators are. So perhaps it’s not too big a deal if someone just starts using them?

On the other hand, the use of !, && and || is so entrenched that it might be difficult for people to adjust to seeing English words in their place.

Do you think alternative operator tokens should be used more?