C++ Logo

STD-PROPOSALS

Advanced search

Subject: Re: [std-proposals] eq keyword and multi-token alternative operators
From: Arthur O'Dwyer (arthur.j.odwyer_at_[hidden])
Date: 2020-10-17 21:18:58


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.
>

Why?
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.

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.
https://godbolt.org/z/cqKWsT

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.

-Arthur



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

Standard Proposals Archives on Google Groups