Thank you Jens for the answer,

I could check
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p2953r4.html
[2] https://github.com/cplusplus/draft/pull/9153
[3] https://github.com/cplusplus/draft/pull/9153/files

interesting about restrictions.

I do see that point 1) is solved, through the modified wording
(from [3]) that well specifies what 'C' is (the class type).

The program is ill-formed
if an explicitly defaulted special member function $\tcode{F}_1$
of class \tcode{C}


However, I still see point 2) in place
about [class.copy.assign]-p12.

Do you believe that the wording:

The implicitly-defined copy/move assignment operator for
a non-union class X performs memberwise copy/move
assignment of its subobjects.

formally matches even the case of explicit object parameter ?
The rules from [dcl.fct.def.default] restrict to have no more than
same-class reference as type for the explicit object parameter,
so the intent is quite clear. Do you believe it is also formally correct
to use "its" (subobjects) when the subject is the explicit object
parameter instead of *this ?

Il giorno sab 4 lug 2026 alle ore 18:25 Jens Maurer <jens.maurer_at_[hidden]>
ha scritto:

>
> 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 ) ).
> >
>
>