It's sad to see P2128 merged with so little conta-argument,

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

https://github.com/willwray/n2740/blob/main/P2128_rebuttal.md

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.

On Mon, Oct 4, 2021 at 7:06 AM Corentin via Liaison <liaison@lists.isocpp.org> wrote:

On Mon, Oct 4, 2021 at 12:17 PM Ville Voutilainen <ville.voutilainen@gmail.com> wrote:

On Mon, 4 Oct 2021 at 12:57, Corentin <corentin.jabot@gmail.com> wrote:
>
>
>
> On Mon, Oct 4, 2021 at 11:22 AM Ville Voutilainen via Ext <ext@lists.isocpp.org> wrote:
>>
>> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2128r6.pdf
>>
>> Did we ever discuss this in a liaison group meeting?
>>
>> While the paper is not proposing to add multi-dimensional subscripting
>> for raw arrays, it is doing a land grab on what that syntax means.
>> I got the impression that some WG14 members have different ideas
>> for that sort of a syntax, based on earlier email discussions.
>
>
> As far as I understand, the concerns were about comma expressions,
> and that ship has sailed with the depreciation in 20.

One of the different ideas is in
https://lists.isocpp.org/liaison/2021/04/0472.php.

This has been discussed in various subgroups (SG14 notably),

and afaik that person position's had no consensus.

I'm adding Mark to the mail to make sure he can address it.

The  premise that "in C++ [] should return an lvalue" is not based in existing practices. As observed, the proposal does not dictate the value category of the return object.

So, I am not sure how this is a SG22 matter. C has no reference, if a similar proposal was adopted in C, it would be limited to lvalue (Similarly, C functions return lvalues, c++ functions and call operators might not, and none of the containers return an actual lvalue).

If anything, this proposal alleviate the need of proxies by allowing to index the underlying object directly instead of having[muliple][intermediate][proxies].

So, from what I understand, this person objects to the C++ proposal as a whole, rather than it being a C compatibility concern.

 

> To my knowledge, none of the authors has been reached about further C
> compatibility concerns.
> And as you are pointing out, this proposal does not affect C arrays.

Sure, but once we do this land grab of what the syntax means, doing
the same for C
arrays becomes a consistency fix rather than a novel addition, and the pathways
leading to possible other meanings of the syntax are closed. Which is what the
email linked above is talking about.

At any rate, I'm not advocating either way here, I was just asking
whether we ever managed
to have a liaison meeting discussion about this.

_______________________________________________
Liaison mailing list
Liaison@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
Link to this post: http://lists.isocpp.org/liaison/2021/10/0844.php