-1

Why we cannot overload subscript operator using friend function

Akhil Prasad
  • 11
  • 1
    Please explain, what is `operator[]` as a free function. – 273K Aug 14 '22 at 17:55
  • 3
    It's a requirement that the subscript [operator](https://en.cppreference.com/w/cpp/language/operators) is a member function, because you can't have a subscript without an object. – Some programmer dude Aug 14 '22 at 17:55
  • 3
    Quick answer - because the standard says so. – lorro Aug 14 '22 at 17:55
  • 1
    @Someprogrammerdude You literally have `[]` before objects: this comes from c-style arrays, e.g., `int[]`. In that case, it's a built-in. There's no actual issue with designing a C++-like language where `operator[]` is implementable as a free function; but C++ committee never decided to go that way. – lorro Aug 14 '22 at 18:17
  • @lorro `int[]` is a *type* (an incomplete type), not a subscript expression. – Some programmer dude Aug 15 '22 at 18:33

2 Answers2

0

Not all operators can be overloaded. For those that can be overloaded there are rules whether they can be non-members or not. For details I refer you to https://en.cppreference.com/w/cpp/language/operators.

The operators that can be overloaded only as members are =,(),[] and ->.

463035818_is_not_an_ai
  • 109,796
  • 11
  • 89
  • 185
0

Let's add overloading to a language that is derived from C. Did you know that the built-in operator is symmetric? For raw arrays it's always true that a[i] == i[a]. It's an emergent property that may be cute, but hardly conducive for great code.

So, wouldn't it be a good idea to limit our overloading to only have our "container object" on the left? Many will say yes. And it is also true that the left-hand side of an expression is always taken as this for member lookup.

Now if we only want to allow the object on the lhs, the choice is easy: only allow defining the operator as a member. For a similar reason operator= is a member-only operator too, because the object being assigned to only makes sense (to the language designer) on the left.

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
  • Correct me if I’m mistaken, but doesn’t `operator ->*` also have this property, but is allowed to be overloaded as a free function? It makes sense given the special nature of `operator =` that it should be a member, but I don’t see any intrinsic reason why `operator []` couldn’t have been defined as a free function or as a friend. – templatetypedef Aug 14 '22 at 18:57
  • @templatetypedef - There's hardly an intrinsic reason for anything, `operator=` could be a free function too if someone wanted to design a language where it may be one. Overload resolution would work just the same. The only problem is if someone decided to be cute and overload it in a way that `5 = a` assigns to `a`. It's idiosyncratic and weird, but hardly a violation of some natural law. `5[a]` is cut from the same cloth, though arguably people seem to be far more accepting of it. Bjarne had a right to consider it not a good idea in overloading, and to force it to be a member. – StoryTeller - Unslander Monica Aug 14 '22 at 19:01
  • Gotcha. Though I could imagine some weirdness if `operator=` was free function and the compiler had to defer figuring out whether to autogenerate it. :-) – templatetypedef Aug 14 '22 at 19:12
  • @templatetypedef - All to true. Gotta love a language designed with so many opposing forces in play :) – StoryTeller - Unslander Monica Aug 14 '22 at 19:16