[BUG] Permit `operator=` with `in this` (via function metafunction `@proxy`)

[JohelEGP]

Title: Permit operator= with in this.

Description:

operator= sets the value of this object, so the this parameter can be anything but in (which would imply const)
-- https://github.com/hsutter/cppfront/wiki/Cpp2:-operator=,-this-&-that#operator-is-the-name-for-all-value-setting-functions-construction-assignment-conversion-and-destruction.

There are use cases when the target of assignment isn't part of the value of this.
For example: https://eel.is/c++draft/pairs#lib:operator=,pair_.

[jcanizales]

What is the use case for an assignment on a const object of type pair?

[JohelEGP]

It was added for:

P2321R2 zip (Tim Song)

And I think it's also used for:

P0429R9 A Standard flat_map (Zach Laine)

Rationale seems to be, in order, at

• https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2214r0.html#a-tuple-that-is-writable
• https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2214r0.html#a-tuple-that-is-readable
• https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2321r2.html#proxy-reference-changes

[jcanizales]

Ouch that reads like such a hack... Maybe we could treat it like the weird constructor of vector, and let it happen in C++ code but not be forced to allow someone writing it again in Cppfront.

[JohelEGP]

Another use-case is std::ignore: https://en.cppreference.com/w/cpp/utility/tuple/ignore.

[Dooez]

This behaviour is useful for proxy references, maybe it should only be allowed if the class is immutable, so no data members are present, or all members are const?

[JohelEGP]

Because const data members have pitfalls, we use pointers instead.
See https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-constref.

[Dooez]

I suggest restriction of immutability to isolate a situation of assignment being const to cases where it is required.

The types that operator=(...) const are usually used in should not be copy-assignable and movable, so having const members does not affect them in the way described in your link.

Proxy references, such as vector<bool> reference or zip_view reference or a tuple of references(for example from std::tie()) all need to have const assignment operator. But since they are "references" they are immutable, and once constructed cannot be changed. Assigning something to a reference is not intended to change the reference, it is intended to change whatever the reference points to.

So having const data members (for example const pointers) is somewhat approriate in such types, and these types are required to have const assignment.

[JohelEGP]

Class template atomic_ref is one example for which such requirement wouldn't work.
See https://eel.is/c++draft/atomics.ref.generic.
It has a const operator=, and behaves like a value type.
It has:

    T operator=(T) const noexcept;

🔗
T operator=(T desired) const noexcept;
11
#
Effects: Equivalent to: store(desired);
return desired;

[JohelEGP]

It has a const operator=, and behaves like a value type.

Or maybe not.
It has atomic_ref& operator=(const atomic_ref&) = delete;.

[JohelEGP]

Maybe https://eel.is/c++draft/template.slice.array is a better example.
It seems there are other *_arrays accompanying valarray with reference semantics that are copyable.

[JohelEGP]

I suppose I'd like to be able to implement view types with deep copy semantics.
I think https://wg21.link/P1085 touches on the topic.

[Dooez]

Maybe https://eel.is/c++draft/template.slice.array is a better example. It seems there are other *_arrays accompanying valarray with reference semantics that are copyable.

According to the link

void operator=(const valarray&) const;
const slice_array& operator=(const slice_array&) const;
These assignment operators have reference semantics, assigning the values of the argument array elements to selected elements of the valarray object to which the slice_array object refers.

So they are not copy assignable if i'm not mistaken.

[Dooez]

View with deep copy on assignment would not meet view semantic requirements i think.
And at the moment i don't see the need for const deep copy assignment operator.