Oops SG19 Machine Learning (not SG22).
Maybe we should name Groups by name rather than number...


On Mon, Oct 4, 2021 at 8:12 AM will wray <wjwray_at_[hidden]> wrote:

> 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
>>
>