https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106520
Bug ID: 106520
Summary: 2+ index expressions in build_op_subscript are
incorrectly interpreted as comma expression
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mkretz at gcc dot gnu.org
Target Milestone: ---
Commit b38c9cf6d570f6c4c1109e00c8b81d82d0f24df3 implemented Multidimensional
subscript operator [PR102611]. However, the backwards compatibility leads to
surprising results. E.g.:
struct A
{
void operator[](unsigned);
void operator[](unsigned, unsigned);
};
struct B
{
explicit operator unsigned() const;
};
void f(A a, B b)
{
a[1];
a[b, 2];
}
Compiles to two calls to A::operator[](unsigned) with the following
diagnostics:
<source>: In function 'void f(A, B)':
<source>:15:4: warning: top-level comma expression in array subscript changed
meaning in C++23 [-Wcomma-subscript]
15 | a[b, 2];
| ^
[https://godbolt.org/z/f6vf3x5Gv]
The user probably intended to call the two-index subscript overload. But
there's no indication why the call failed. The warning is probably puzzling to
most users. It's probably not obvious to most users that the "wrong" function
gets called.
I'm not sure the compatibility issue is worth it. I think it would be better to
call build_op_subscript with unmodified complain and let code that turns on
-std=c++23 break if it relies on comma expressions in subscripts.
