> I think it would make sense to schedule P2128 for discussion in SG22
> sooner rather than later in case there is actionable feedback from the
> study group.

Yes, please.

> If someone has veto-level concerns about the paper due to
> compatibility with C, I would highly encourage them to write
> a paper for SG22 that we can also discuss in June

My concern is for compatible language evolution of C and C++.
I believe this is veto-worthy, and believe this is worth SG22 time.
I can summarise this Liaison case against P2128 in a paper
(may need some help with correct iso formatting).

...

I see agreement here that a[i...] is valuable syntactic turf.
Therefore, caution should be exercised here.
As the authors say - "the timeline is aggressive".
Waiting a cycle would be prudent, to allow appropriate reflection.

After all, P2128 offers no new functionality with operator[]
"Both its use and definition would match that of operator()."

But should it? Nothing is broken, for now.
The generalisation adds nothing yet devalues alternative meanings.
It is a waste of committee time. There are many more important things.

EWG asked for more motivation. None was provided.

IIUC Jens M. is saying DoN't PaNiC!
This is mostly harmless. It doesn't really affect C.

I disagree. The harm is insidious.
It's stated motivating use case damages expectations.
It tends to perpetuate a particular world view. It devalues.

The sentence that Martin highlighted, and it's updated version,
appear to show a lack of knowledge of C array fundamentals.

It is yet another example of a well-meaning proposal,
poorly motivated and not sufficiently thought through,
yet likely to be accepted as a cool new bit of syntax.




On Mon, Apr 26, 2021 at 8:15 AM Aaron Ballman via Liaison <
liaison_at_[hidden]> wrote:

> On Mon, Apr 26, 2021 at 2:21 AM Jens Maurer via Liaison
> <liaison_at_[hidden]> wrote:
> >
> > On 26/04/2021 07.51, Uecker, Martin wrote:
> > > Am Montag, den 26.04.2021, 07:45 +0200 schrieb Jens Maurer via Liaison:
> > >> On 26/04/2021 00.31, will wray via Liaison wrote:
> > >>> auto&& e = a[i]; // retains lvalueness
> > >>> // suboptimal for proxy
> > >>
> > >> What's suboptimal about the proxy case here?
> > >>
> > >> This seems to get way off-topic for the liaison list, btw.
> > >>
> > >> The only part of the proposal that affects the common
> > >> subset of C and C++ is the fact that the comma operator
> > >> can no longer be used unparenthesized inside [].
> > >>
> > >> Other than that, this is a user-defined overloaded operator,
> > >> a feature that C doesn't have. Hardly any extension for
> > >> built-in types that C might contemplate is precluded by that.
> > >
> > >
> > > If C++ adopts this proposal now and encourages use of a[3,2] for
> > > multi-dimensional indexing, then later people would not
> > > object if C decides to use the syntax a[3,2] for something
> > > else for C arrays?
> >
> > I don't know.
> >
> > Some observations:
> >
> > - The liaison group, at best, will inform the WG21 and WG14
> > committees about points of conflict or concern. It has no
> > veto powers in either venue.
>
> Correct, though when the compatibility group says "this will cause
> consternation for the other committee in these concrete ways", that
> feedback should be balanced against "we can make decisions that are
> best for our committee" kinds of rationale. It's not really a veto so
> much as a warning to anticipate a greater potential for NB-level
> comments coming in on a proposal.
>
> > - As explained earlier, there are a number of situations where
> > the common use of an overloaded operator in C++ bears no semantic
> > relationship to the meaning of the operator on built-in types.
> > On the other hand, those other uses are semantically further apart
> > than C-style array vs. C++ near-array classes.
> >
> > - Part of the concern here is timing. The C++ proposal has
> > a good chance to get into C++23. If there were a specific
> > proposal for C2x that would cover this area, it would probably
> > inform the C++ proposal. As far as I know, there isn't.
> >
> > - Practically speaking, attempting to stop the WG21 proposal
> > from advancing for concerns about hypothetical future WG14
> > evolution would seem to require quite a bit of persuasion,
> > given that WG21's Evolution Working Group has already established
> > informal consensus on the proposal, and is about to verify
> > this consensus using a several-week online ballot.
> >
> > Aaron, what would be suitable next steps here?
>
> I think it would make sense to schedule P2128 for discussion in SG22
> sooner rather than later in case there is actionable feedback from the
> study group. June is the earliest time slot I have available. If
> someone has veto-level concerns about the paper due to compatibility
> with C, I would highly encourage them to write a paper for SG22 that
> we can also discuss in June at the same time.
>
> ~Aaron
>
> >
> > Jens
> > _______________________________________________
> > Liaison mailing list
> > Liaison_at_[hidden]
> > Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> > Link to this post: http://lists.isocpp.org/liaison/2021/04/0481.php
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/04/0486.php
>