Date: Mon, 4 Oct 2021 21:08:02 +0200
On 04/10/2021 13.25, Ville Voutilainen via Liaison wrote:
> On Mon, 4 Oct 2021 at 14:05, Corentin <corentin.jabot_at_[hidden]> wrote:
>> The premise that "in C++ [] should return an lvalue" is not based in existing practices. As observed, the proposal does not dictate the value category of the return object.
>> So, I am not sure how this is a SG22 matter. C has no reference, if a similar proposal was adopted in C, it would be limited to lvalue (Similarly, C functions return lvalues, c++ functions and call operators might not, and none of the containers return an actual lvalue).
>> If anything, this proposal alleviate the need of proxies by allowing to index the underlying object directly instead of having[muliple][intermediate][proxies].
>
> The gist of the matter is not lvalues and proxies, it's
>
> "A more useful core language meaning might be:
>
> int a[4] = {1,2,3,4};
>
> a[1,2] = a[2,1]; // swap
> a[1,2,3,0] = a[0,1,2,3]; // it's a rotate !
> "
>
>> So, from what I understand, this person objects to the C++ proposal as a whole, rather than it being a C compatibility concern.
>
> It's a question of one committee performing a syntactic and semantic
> land grab, and that constraining what the other committee
> can evolve their language to. That makes it a liaison concern. Thus my
> question whether this was ever discussed in a SG21
> meeting. Thus far I'll take these responses as a "no".
I think I've seen e-mail traffic, but I don't remember a discussion in SG22.
That said,
- WG21 has deprecated the comma operator in [] in C++20.
While that's technically a compatibility break with C, it's still
easy to write code that's valid in both languages, and the
assumption is that the comma operator appears only rarely
in C inside []. In my view, that means little practical harm.
- P2128 only reserves the core language syntax, but does not
propose a specific meaning for x[a,b,c] other than calling
an overloaded operator. It would be very well possible for
that overloaded operator to implement the semantics above:
> a[1,2] = a[2,1]; // swap
> a[1,2,3,0] = a[0,1,2,3]; // it's a rotate !
Whether that becomes the "de facto" interpretation depends on
some library getting into the standard that actually overloads
that operator to have a certain meaning. My guess is that
mdspan might be that paper.
So, there's still time for WG21/WG14 to discuss the desired
meaning, until mdspan hits the Working Draft.
(And it's certainly conceivable to oppose the mdspan paper
on the grounds that it defines semantics for x[a,b,c]
that are not clearly superior to any other semantics that
expression could have.)
Of course, WG14 will be fully busy with C23, so it'll be
very difficult to slot in such a hypothetical discussion
if we still want to resolve the matter for C++23.
If, however, mdspan goes into C++26, we have more time to
discuss.
Jens
> On Mon, 4 Oct 2021 at 14:05, Corentin <corentin.jabot_at_[hidden]> wrote:
>> The premise that "in C++ [] should return an lvalue" is not based in existing practices. As observed, the proposal does not dictate the value category of the return object.
>> So, I am not sure how this is a SG22 matter. C has no reference, if a similar proposal was adopted in C, it would be limited to lvalue (Similarly, C functions return lvalues, c++ functions and call operators might not, and none of the containers return an actual lvalue).
>> If anything, this proposal alleviate the need of proxies by allowing to index the underlying object directly instead of having[muliple][intermediate][proxies].
>
> The gist of the matter is not lvalues and proxies, it's
>
> "A more useful core language meaning might be:
>
> int a[4] = {1,2,3,4};
>
> a[1,2] = a[2,1]; // swap
> a[1,2,3,0] = a[0,1,2,3]; // it's a rotate !
> "
>
>> So, from what I understand, this person objects to the C++ proposal as a whole, rather than it being a C compatibility concern.
>
> It's a question of one committee performing a syntactic and semantic
> land grab, and that constraining what the other committee
> can evolve their language to. That makes it a liaison concern. Thus my
> question whether this was ever discussed in a SG21
> meeting. Thus far I'll take these responses as a "no".
I think I've seen e-mail traffic, but I don't remember a discussion in SG22.
That said,
- WG21 has deprecated the comma operator in [] in C++20.
While that's technically a compatibility break with C, it's still
easy to write code that's valid in both languages, and the
assumption is that the comma operator appears only rarely
in C inside []. In my view, that means little practical harm.
- P2128 only reserves the core language syntax, but does not
propose a specific meaning for x[a,b,c] other than calling
an overloaded operator. It would be very well possible for
that overloaded operator to implement the semantics above:
> a[1,2] = a[2,1]; // swap
> a[1,2,3,0] = a[0,1,2,3]; // it's a rotate !
Whether that becomes the "de facto" interpretation depends on
some library getting into the standard that actually overloads
that operator to have a certain meaning. My guess is that
mdspan might be that paper.
So, there's still time for WG21/WG14 to discuss the desired
meaning, until mdspan hits the Working Draft.
(And it's certainly conceivable to oppose the mdspan paper
on the grounds that it defines semantics for x[a,b,c]
that are not clearly superior to any other semantics that
expression could have.)
Of course, WG14 will be fully busy with C23, so it'll be
very difficult to slot in such a hypothetical discussion
if we still want to resolve the matter for C++23.
If, however, mdspan goes into C++26, we have more time to
discuss.
Jens
Received on 2021-10-04 14:08:08