C++ Logo

liaison

Advanced search

Re: [wg14/wg21 liaison] [isocpp-ext] P2128, multi-dimensional subscript operator

From: Uecker, Martin <Martin.Uecker_at_[hidden]>
Date: Mon, 4 Oct 2021 11:37:24 +0000
Am Montag, dem 04.10.2021 um 07:25 -0400 schrieb Aaron Ballman via
Liaison:
> On Mon, Oct 4, 2021 at 5:57 AM Corentin via Ext
> <ext_at_[hidden]> wrote:
> > On Mon, Oct 4, 2021 at 11:22 AM Ville Voutilainen via Ext
> > <ext_at_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.
> > I suppose C might want to talk about doing something similar there,
> > as that did
> > technically include an incompatibility.
> >
> > 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.
>
> Does it impact the design space of C by nailing down a particular
> meaning for the recently deprecated syntax from C++20 that's never
> been deprecated in C? If so, I think it's reasonable if members of
> SG22 (or either of the greater WGs) want to see this paper as a
> compatibility issue. Thus far, I've not gotten any such requests and
> the syntax is mostly outside of what typically shows up in shared
> header files, so I've not requested an SG22 review personally.

I would be all for limiting the focus regarding cross-language
compatibility to real practical concerns (i.e. mostly headers), but
this did not seem a majority opinion in the past.

Can we please develop a consistent position here? Because I fully
expect people to object to future C language changes in this area
when C++ does something different here.

Martin


Received on 2021-10-04 06:37:31