C++ Logo


Advanced search

Subject: Re: [std-proposals] eq keyword and multi-token alternative operators
From: Jason McKesson (jmckesson_at_[hidden])
Date: 2020-10-18 01:19:08

On Sun, Oct 18, 2020 at 1:57 AM Walt Karas via Std-Proposals
<std-proposals_at_[hidden]> wrote:
> 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.
> 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.
> 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).

What about it? You're not going to get literally millions of lines of
C++ code changed to use this new keyword. You're not going to get
thousands and thousands of C++ programmers to use your new keyword
instead of `eq`. All you'd be doing is satisfying one small corner of
the language.

Maybe 30+ years after such a change, we would see `eq` being used
instead of `==`. But probably not, since *dozens of other languages*
still use `==`, so users of those languages will proliferate its use
into C++.

Besides, we already have a perfectly adequate solution to this
problem: compilers warn when you use `=` in suspicious places. Adding
a keyword to fix a problem that's already reasonably well handled
seems fruitless.

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

Standard Proposals Archives on Google Groups