Am Montag, den 26.04.2021, 08:20 +0200 schrieb Jens Maurer:
> 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.
>
> - 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?

Let me clarify my position.


* Speaking for me, I do not have serious concerns about this
paper and it is fine with me if this goes forward on the
C++ side.


* I agree with Jens G that WG14 should then consider
deprecating the use of the comma operator inside [].


* I do not agree with Jens G that multi-dimensional indexing
is the only conceivable use of this syntax. In fact, I tend
to agree with Will that extracting a set of elements seems
more useful as a core feature, and I also suspect that there
might be better alternatives for multi-dimensional indices.
In general, I think this needs much more thought and a good
plan about how to evolve arrays.


* In principle, we should find a consensus if we want to
maintain a common core syntax. Then I think we should
(for future papers) jointly discuss proposed syntax changes
as early as possible. That C does not have a similar proposal
is then not a good argument that C++ can proceed independently,
because I do not think this should be a race about who claims
syntax first. Alternatively, I am also good if we agree that
t it is fine if both languages can diverge a bit more. I just
think it is important to find a consensus here.


Best,
Martin