With several uses of [x, y, z, ...]-clause syntax, shouldn't operator[] be allowed to accept multiple parameters?

Question

Since C++11 we can write lambdas such as:

auto foo = [a, b]() { return a+b; };

with a square-bracketed capture clause, in which items are separated by commas. In C++17 we'll be able to use structured bindings:

for (const auto& [name, description] : planet_descriptions) {
    std::cout << "Planet " << name << ":\n" << description << "\n\n";
}

which is another example of a comma-separated square-bracketed clause.

Yet, we cannot override a class' operator[] to take several parameters, e.g. this:

template<typename V, typename I, typename J>
const V& operator[](I i, J j) const {
    return data_[width() * i + j];
}

will not compile.

I know there are workarounds - many are mentioned here:

C++ [] array operator with multiple arguments?

But - why are the former part of the language while the latter impossible even as an overload at the programmer's discretion? Is it simply because nobody has proposed otherwise, or is there some specific reason for it?

Notes:

• Yes, of course this will create ambiguity / incompatibility with using the comma operator in a call to a unary operator[]: x[a, b] would be either operator[](operator,(a,b)) or operator[](a,b). However, we have sort-of the same ambiguity with round brackets: foo(a,b) might be a call to a binary foo() with a and b, or it might be foo(operator,(a,b). The language standard simply decrees it's the former rather than the latter (or that the former should be preferred); the same preference could be decreed for square brackets. In fact, if I'm not mistaken that will not actually break any existing code - since existing code won't have a binary operator[] to prefer.
• The example binary operator[] is just an example, not something I want to implement.

Answer 1

It's certainly an option, although surprising to many, given the general tendency to stick to C syntax for operators familiar to C programmers.

It's also not a new idea, Gabriel Dos Reis suggested it in 2014. The last-documented state of the idea from Uniform handling of operator[] and operator() is follows:

In c++std-core-14770, Dos Reis suggests that operator[] and operator() should both be allowed to be static. In addition to that, he suggests that both should allow multiple parameters. It's well known that there's a possibility that this breaks existing code (foo[1,2] is valid, the thing in brackets is a comma-expression) but there are possibilities to fix such cases (by requiring parens if a comma-expression is desired). EWG should discuss whether such unification is to be strived for.

Discussed in Rapperswil 2014. EWG points out that there are more issues to consider here, in terms of other operators, motivations, connections with captureless lambdas, who knows what else, so an analysis paper is requested.

So to paraphrase that eminent C++ language theorist: If you like it then write a paper on it.