This proposal is poorly motivated and deleterious, IMO.
Unfortunately it is popular / populist so acceptance looks likely.
That'll be a mistake as it is an actively damaging change.
Let me explain (at least so I can say "told you so").
The R5 revision states that EWG requested more motivation.
The new R5 motivation simply rearranges previous prose into
a sequence of bullet-points with (Clouseau style) conclusion:
• Therefore, we should let operator[] take multiple arguments.
Please Non! What's the problem?
In C, the subscript operator returns a subobject lvalue. Good.
In C++, subscript operator overload should follow suit - it does,
mostly, but vector-of-bool returns proxy-reference instead -
this is now generally accepted as a very nasty design flaw.
In C++, multi-indexing is done with paren function-call syntax.
This is by now well established practice and is semantically fine.
Multi-indexing is indeed a functional mapping, often partial.
(P2128 protests parens "carry the
wrong semantic implications").
Paren multi-indexing could just as easily (or more easily) be
extended to C, as nested C array has natural partial indexing.
Multi-indexing is most powerful when partial-indexing can return
a proxy reference, i.e. not necessarily an actual subobject.
When indexing with parens, devs know to expect a proxy result.
So, there is a clear semantic distinction with the status quo:
[i] means subobject indexing, returning a language lvalue
(i...) means multi-indexing, possibly partial, returning a proxy
This proposal adds:
[i...] what does this mean?
With operator overloading, it could mean anything at all.
The intended "motivating" use case conflates subobject vs proxy;
an infamous gotcha and dangerous pitfall.
Devs will have to carefully check the semantics.
P2128 is proposing something unprecedented - to add a new
C++ operator that has no current core language meaning.
This might constrain future language evolution, C and C++.
A more useful core language meaning might be:
int a[4] = {1,2,3,4};
a[1,2] = a[2,1]; // swap
a[1,2,3,0] = a[0,1,2,3]; // it's a rotate !
Of course, this _could_ be done with the proposed C++ overload.
That's the problem - it _could_ do anything - anything at all.
It muddies what is currently a clear semantic distinction.