C++ Logo


Advanced search

Re: [wg14/wg21 liaison] Multidimensional subscript operator

From: Jens Maurer <Jens.Maurer_at_[hidden]>
Date: Mon, 26 Apr 2021 13:18:29 +0200
On 26/04/2021 08.58, Jens Gustedt wrote:
> 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.

Sounds good, if WG14 is happy with the backward compatibility break 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.

In fact, I think [] is symmetric: a[i] is identical to i[a].

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

Maybe that needs a bit more consideration than the restriction to
"assignment-expression" to free up the syntax space.


Received on 2021-04-26 06:18:37