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
