not that I didn't try to do my part...
There might be lessons here for the WGs in how to better
accommodate discussion of counter arguments from
non-ISO participants, with no access to wiki or reflectors.
I'd raised concerns about P2128's plans for operator[]
in Spring 2020, not long after the R0 paper was published,
directly to the paper authors (as is the recommended way).
After some persistence, Mark responded:
> My personal preference is that either x(i,j,k) or x[i,j,k] work,
> and I don't care which, as long as P0009 in either form
> makes it into the Standard.
Daisy Hollman also joined the discussion
(also from the mdspan viewpoint).
Corentin didn't respond (I still don't understand his support
for mdspan-motivated P2128 while a vocal critic of 1D span).
The concerns I'd raised were not understood or addressed.
In the mdspan design, index expressions have to be full-rank,
that is, have exactly the number of indices as there are extents.
It's the case of partial-indexing that raises the issue of proxy-
returning operator[] - a design space ignored by P2128.
I repeatedly asked to be invited to any telecon where P2128
was discussed (including by posting on the GitHub issue -
the post was deleted as inappropriate / not procedural).
I was not invited to any telecon.
Following the Liaison email discussion, I wrote a rebuttal paper
I gave a 'practice' presentation to SG22 Machine Learning.
Paper author Izzy Muerte attended and participated in the Q&A.
Following that, there seemed little point in continuing.
P2128 was popular and was on course to merge.
I didn't submit the rebuttal paper to WG14.
Enough time had been wasted - mine and the committees.
It was a potential Liaison issue; I still see it that way,
but Liaison has more pressing issues to deal with.
Assuming 'multi-dimensional' meaning for variadic subscript
breaks with C's single-subscript builtin operator[] and
devalues subscript semantics in both C and C++.
C succeeds as much for what's left out as for what's included.