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.

Jens