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_at_[hidden]> wrote:

>
>
> On Mon, Oct 4, 2021 at 12:17 PM Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
>> On Mon, 4 Oct 2021 at 12:57, Corentin <corentin.jabot_at_[hidden]> wrote:
>> >
>> >
>> >
>> > On Mon, Oct 4, 2021 at 11:22 AM Ville Voutilainen via Ext <
>> ext_at_[hidden]> 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_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/10/0844.php
>