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

+1; would you be interested in writing a paper on the topic?

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

Agreed, but one complicating factor is that the comma operator within
an array subscript was deprecated in C++20, before there was an SG22.
So in some ways, the incompatibility damage was already done.

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

That's fair. I bring it up because we have a gigantic laundry list of
incompatibilities where the same source code has different meaning
depending on which language you're compiling in. I've been working on
a document to detail just how bad it's gotten and it's got ~20 pages
of very short examples (I hope to publish it in the near future btw).
So the concern about an arms race is a good one to raise, but at the
same time, this is an area of economic harm in practice that we
shouldn't exacerbate.

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

That's generally been my view of how we responsibly evolve these
languages, but that's something that needs to be decided on the WG14
and WG21 level rather than on the SG22 level. I mean that for both the
common core language as well as for the process of going through both
committees. But if anyone wanted to drive those efforts, writing a
proposal to start getting SG22 buy-in would be fantastic!

~Aaron

>
>
> Martin
>
>