On Mon, Oct 4, 2021 at 7:37 AM Uecker, Martin
<Martin.Uecker_at_[hidden]> wrote:
>
> 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_[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.
> > > 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.

I'm all for a consistent position! Given the volume of proposals that
come into both WG21 and WG14, it is basically impossible for one
person to read all of the papers to see whether there's enough
material in any given one to send it to SG22. So the process thus far
has been that a document comes to SG22 if:

* The author marks SG22 explicitly when uploading a document to the
WG21 document tracker
* The author requests it of me (either on a mailing list or privately)
* A chair or convener requests it of me (either on a mailing list or privately)
* I notice an obvious oversight where one of the above three points
did not happen when it should have
* If anyone (on either committee) other than a chair/convener requests
a document be seen by SG22, I go read the document to see if I agree
there's material there to be discussed and add it on a case-by-case
basis, erring on the side of adding it to the schedule if I'm in
doubt.

So I agree with you that this is not consistent in terms of what
subject material gets seen. If there are suggestions for a better
approach, I'd love to hear them. Bonus points if those suggestions
come in paper form so I can schedule something for SG22 to discuss.

For me personally (not speaking as chair), the watermark for what I
consider to be critical for SG22 to view is whether the feature is
likely to show up in a header file that's shared between C and C++, is
some sort of common expression to see in either language, or is
already existing syntax in one language but with a different meaning
than what's proposed. Basically, the kinds of things that
traditionally have caused economic harm when we've gotten them wrong.

~Aaron