Repository navigation
[SUGGESTION] Support (some) C++ alternative tokens #304
Description
Activity
I think logical operators
and,orandnotare completely different from bitwise operatorsbitand,bitor,xorandcompl, because bitwise operators calculate the result of expressions just like+,-,*,/and other arithmetic operators but logical operators are for decision making similar toisandaskeywords in C++2. Therefore it's reasonable to have&&,||and!as keywordsand,orandnotsimilar toisandas, but bitwise operators&,|,^and~are arithmetic operators and they should not be keywords.I think having the bitwise operators spelled out would eliminate more ambiguity than spelling out the logical operators. For example:
a&&b; //what if a and b are not bool? This is the kind of context cpp2 tries to eliminate ig?That would also reserve
^for pointer deference(wow!!) and could also eliminate ambiguity between bit shift operators and when writing template template parameters.notis another one I use. So much that I have Clang-Format insert a space after!so that it stands out in case I forget to use it (! x->not x).In Cpp2, they should be keywords, not alternative tokens. Then there's no chance you can use it weirdly, like in Cpp1 (e.g.
x and = y;).How would we write
x != ywith this change? Or is the plan to support both tokens?I did notice that
not_eqis a thing when checking out https://eel.is/c++draft/lex.digraph as I wrote this proposal.I'm not proposing banning using operators. So you choose to write it however you like. Including using
std::not_equal(x, y).There's some mentions of an
andkeyword and more starting at #152 (comment).
I prefer writing (
and,or) to (&&,||). Currently, they're treated as identifiers. Socppfrontemits an error if used C++1-correctly (x = y and z;, 3 identifiers in a row is ill-formed), or emits bad C++1 code (x = and;).https://github.com/hsutter/cppfront/wiki/Design-note%3A-Postfix-unary-operators-vs-binary-operators talks about "alternative tokens". It seems they were supported at some point before this repository was published.
Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code? No (my guess).
Will your feature suggestion automate or eliminate X% of current C++ guidance literature? No (my guess).
Describe alternatives you've considered.
_and, with no portable way to name them from C++1).