P2953R5 Adding restrictions to defaulted assignment operator functions

was approved in Brno and fixes this.

Jens



On 7/4/26 14:01, mauro russo via Std-Discussion wrote:
> Hello,
>
> pls, pay attention to this possible couple of formal ambiguities
> in the standard:
>
> around the possible differences that the signature for the assignment
> operators may have, compared to the implicitly-declared ones, when
> the default implementation is required through '= default',
> (F1 being the explicit used signature and F2 the one that compiler
> would have used in case of implicit declaration)
>
> [dcl.fct.def.default]-p(2.4) reads:
>
> if F2 has a non-object parameter of type const C&, the corresponding
> non-object parameter of F1 may be of type C&.
>
> However, since the text never makes explicit what 'C' is, it is
> theoretically possible to think C as MyClass&, which would make the
> aforementioned text ineffective (while remaining correct) because
> the const qualifier becomes useless.
>
>
> The other point is that, since [dcl.fct.def.default]-p(2.2) reads
>
> if F2 has an implicit object parameter of type "reference to C",
> F1 may be an explicit object member function whose explicit
> object parameter is of (possibly different) type "reference to C",
> in which case the type of F1 would differ from the type of F2 in
> that the type of F1 has an additional parameter;
>
> then the following sentence in [class.copy.assign]-p12:
>
> The implicitly-defined copy/move assignment operator for
> a non-union class X performs memberwise copy/move
> assignment of its subobjects.
>
> is not fully formally correct in my opinion, because 'its subobjects'
> refers. to me, the data members of the object '*this'.
> Some modified wording (or additional note) might be used to cover
> the case of explicit object parameter ( as allowed by [dcl.fct.def.default]-p(2.2 ) ).
>