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