C++ Logo


Advanced search

Subject: Re: [std-proposals] eq keyword and multi-token alternative operators
From: Walt Karas (wkaras_at_[hidden])
Date: 2020-10-18 00:57:12

On Saturday, October 17, 2020, 09:19:10 PM CDT, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote: 

On Sat, Oct 17, 2020 at 8:41 PM Walt Karas via Std-Proposals <std-proposals_at_[hidden]> wrote:
> I suggest adding the keyword "eq"  as an alternative to  the == token.

Especially "why?" because as you point out, the `eq` in `and_eq` already denotes a single equals sign. If you were going to add an English name for the == operator, "eqeq" would make more sense.

WK:  Because of the classic problem of accidentally typing = when you mean ==.  I would have preferred and_by/or_by/xor_by (to and_eq/or_eq/xor_eq).

> bitand= , bitor= , bitxor= seem more clear and consistent to me than and_eq, or_eq, xor_eq.  The pain point is that bitand/bitor/binxor would have to become reserve words rather than just keywords.  With that change, would there be any parsing ambiguities with these sequences of two tokens representing a single operator?

It's C++; there is always a parsing ambiguity.

Trying to make one lexical token out of two tokens is also a huge mess because it interacts with the Maximal Munch Rule. You'd have to invent a way to lex the sequence of characters `bitand==`. Today that means the two tokens `& ==`, but under your rule it seems like you'd want it to become `&= =`? How would you specify that, exactly?

Notice that under today's C++ lexing rules, `bitand&` is not a synonym for `&&`; it's a synonym for `& &`. I consider this a good thing.


WK:  I was only suggesting the three particular two token sequences I mentioned be considered operators.  Not more generally as you are describing.

STD-PROPOSALS list run by std-proposals-owner@lists.isocpp.org

Standard Proposals Archives on Google Groups