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