Can I call the default opAssign after overloading opAssign?

[Dan]

On Sunday, 25 November 2012 at 11:05:37 UTC, monarch_dodra wrote:
>
> AFAIK, there is no "official spec". And even if there was, the 
> "de-facto" spec *is* TDPL... minus everything that could have 
> changed since it's printing.

I think TDPL is great, but there is a doc called "D Language 
Specification" which is the perfect level for reference - it is 
just now outdated and incomplete. Couldn't Walter just open 
source this document and retain final say on the updates? With 
C++ we had the ARM and Stroustrup's book. For D we have the spec 
and TDPL. Put the source of the language spec out in some markup 
language, let others help to bring it up to snuff, generate pdf's 
and other formats. The only tricky part is documenting areas 
where the language designer(s) has open issues without a 
commitment to a solution.

Take the opAssign issue in question. In TDPL 7.1.5.1 we have 
"Recall that Widget holds a private int[] member that was 
supposed to be distinct for each Widget object. Assigning w2 to 
w1 field by field assigns w2.array to w1.array—a simple 
assignment of array bounds, without actually copying the array 
contents. This needs fixing because what we want is to create a 
duplicate of the array in the source Widget and assign that 
duplicate to the target Widget."

He then goes on to describe how user code can intercept opAssign 
to make things right. But, unless I'm missing something, that is 
unnecessary because the default opAssign carries the call to 
postblit (see previous example). Now look at the issue from the 
language spec (Structs & Unions - Assignment Overload):

Struct assignment t=s is defined to be semantically equivalent to:
t = S.opAssign(s);
where opAssign is a member function of S:
S* opAssign(S s)
{   ... bitcopy *this into tmp ...
     ... bitcopy s into *this ...
     ... call destructor on tmp ...
     return this;
}

This description is almost perfect, it just fails to mention 
"...bitcopy and postblit". Both docs are incorrect according to 
the behavior of default opAssign. I think the language spec 
should be fixed first and kept accurate.

Thanks
Dan