0

=> isn't overloadable in C++. I have always wondered whether this is just a pure coincidence or whether there is a specific reason this sequence of two characters cannot be overloaded. The emergence of the comparison operator <=> leads me to believe the former.

I think it's a prime candidate for overloading because it looks like an arrow, which is very common in functional programming syntax and mathematics. Granted -> exists already but having another arrow could be useful to disambiguate between the two. I also don't see how it could break backwards compatibility.

Hisham Hijjawi
  • 1,803
  • 2
  • 17
  • 27
  • 3
    The => operator? Perhaps you mean the >= operator? That should be overloadable. –  Feb 12 '19 at 01:57
  • 1
    @Chipster >= is overloadable, see here https://en.cppreference.com/w/cpp/language/operators – Hisham Hijjawi Feb 12 '19 at 01:58
  • The ternary operator is `? :` while `<=>` is (usually) the comparison operator. In C++ isn't this parsed as `<= >` as two separate things? – tadman Feb 12 '19 at 01:58
  • `Granted -> exists already but having another arrow could be useful to disambiguate between the two.` Between what two? And what for? – DeiDei Feb 12 '19 at 01:59
  • 1
    Are you asking why this isn't a;ready an operator then? –  Feb 12 '19 at 02:02
  • @Chipster yes after reading Jerry Coffins answer that is what I should have asked. – Hisham Hijjawi Feb 12 '19 at 02:04
  • 1
    @tadman `<=>` is the new [three-way comparison operator](https://stackoverflow.com/questions/47466358/what-is-the-operator-in-c) being added in C++20. – Miles Budnek Feb 12 '19 at 02:17
  • 1
    @MilesBudnek Oh, very nice! The spaceship operator from Perl has landed. – tadman Feb 12 '19 at 02:30

2 Answers2

12

C++ only allows you to overload operators that are already operators in the base language.

The base language defined operators, each with its associated precedence and associativity. In an operator overload, you can supply the meaning of that operator (the code that will be executed) for types for a user-defined type (or sometimes, for a combination of two user-defined types).

You cannot, however, just choose an arbitrary set of symbols, and treat it as an operator (no matter how attractive that might be).

There are languages that do allow this--for example, ML (and many of its descendants) allow you to define an operator with an entirely new name that's not part of the base language at all. When you do this, you define the precedence and associativity you want that operator to have. I think that's great, and provides a useful capability--but (at least as the capability is defined in ML) it also has some weaknesses that probably wouldn't fit nearly so well with how things work in C++. I wouldn't expect to see it as part of C++ any time soon (or, probably, ever).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111
  • Correct. The practical upshot is that parsing C++ is a lot easier. A parser can have the list of operators hardcoded. Operator overloading does mean that the next stage of the compiler has to be more complex, but for things like editors the simpler parsing is a significant benefit. (Though C++11 broke those parsers with `>>` contextually closing two template argument lists) – MSalters Feb 12 '19 at 11:29
5

In C++, “overloading” is a mechanism for providing a custom definition for existing operators so they can be used in custom types, not a mechanism for adding new operators to the language. You can’t change the meaning of a “=>” operator because C++ (as of this writing at least) doesn’t have a “=>” operator.

As a supplement to Jerry’s great answer, I want to point out that this was not an oversight by any stretch, but a very conscious design decision. Bjarne Stroustrup, the original creator of the C++ language, describes his thoughts on this in his fabulous book “The Design and Evolution of C++”, as I quote here:

I [Stroustrup] considered it important to provide overloading as a mechanism for extending the language and not for mutating it; that is, it is possible to define operators to work on user-defined types (classes), but not to change the meaning of operators on built-in types. In addition, I didn’t want to allow programmers to introduce new operators. I feared cryptic notation and having to adopt complicated parsing strategies like those needed for Algol68.”

(bold emphasis mine, italics in the original)

Source: Stroustrup, Bjarne: “The Design and Evolution of C++”, Addison-Wesley, 1994. §3.6.5

PS: Although a bit dated as a reference for modern C++ design, this is an excellent and fascinating source to explore the history and the reasoning that led to the design of the original C++ language. The language further design has long been under the purview of an ISO Standards committee but its continuous evolution has continued to be driven by many of the same principles described in the book and Dr. Stroustrup continues to be an important voice in that evolution process.

Euro Micelli
  • 33,285
  • 8
  • 51
  • 70