Jens,

on Mon, 26 Apr 2021 08:20:35 +0200 you (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:
> [...]
> >>
> >> 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.

Practically speaking, I think we could even go further than
that. Using a comma operator within array bounds is the source of much
irritation among new C programmers, and it is a pity that the syntax
allows this. I think some compilers already give a diagnostic and it
would be easy to change the grammar from

      postfix-expression [ expression ]

to

      postfix-expression [ assignment-expression ]

Such a change would be better in line with the function operator, for
example, that also only has assignment-expression, here.

There is the other aspect that in C the subscript operator (and arrays
in general) are only second class in C. The semantics is only
explained as a rewriting from

          a[i] → *(((basetype-of-a*)&a)+(i))

so basically just saving us to write a lot of parenthesis. At some
point I had a proposal to change this to claim a direct access to the
lvalue corresponding to the element to avoid the necessity to go
through address-taking and storage, but that was not well received.

For the future, I cannot reasonably imagine that WG14 would one day
use `a[i, j]` for anything else than multi-indexing, and actually I
would find that a brilliant idea. So why wouldn't we for C23 go to the
change as indicated above, and then for the following change in C26?

      postfix-expression [ argument-expression-list ]

Thanks
Jₑₙₛ

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::