Am Montag, dem 04.10.2021 um 07:51 -0400 schrieb Aaron Ballman:
> 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

I think this is exactly the question where we should try
to formulate a consensus.

The proposal to reuse the comma in [] seems to fall firmly into
the "existing syntax" category as [,] already has a meaning
in C.

I am also not entirely convinced about "already existing syntax
in one language" is the right criterion. It may lead to an
arms race (the committee that grabs the syntax first, wins)
which puts C at a disadvantage and generally may lead to bad
decisions..

If we want to maintain a common core language (syntax-wise) then
all new syntax extensions that are not clearly building
on existing language-specific features should go through
both committees (IMHO). Or, we just focus on headers and let
languages diverge otherwise. Both are acceptable positions
but we need to decide.


Martin