Destructors, const structs, and opEquals

[Andrei Alexandrescu]

On 12/4/10 12:42 AM, Don wrote:
> Officially, opEquals has to have the signature:
>
> struct Foo {
> bool opEquals(const ref Foo x) const {...}
> }

This is a compiler bug. For structs there should be no official 
implementation of opEquals, opCmp etc. All the compiler needs to worry 
about is to syntactically translate a == b to a.opEquals(b) and then let 
the usual language rules resolve the call.

> But this disallows comparisons with rvalues.
> eg,
>
> Foo bar() { Foo x = 1; return x; }
> Foo y=1;
> assert( y == bar() ); // doesn't compile
>
> You can get around this by declaring a non-ref opEquals.
> But this fails if Foo has a destructor.
>
> If a struct has a destructor, it cannot be const(this is bug 3606)
> ---
> struct S {
> ~this() {}
> }
>
> void main() {
> const S z;
> }
> ---
> bug.d(6): Error: destructor bug.S.~this () is not callable using
> argument types ()
> -------
> Likewise, it can't be a const parameter (this is bug 4338).
> void foo(const S a) {}
> It works to have it as a const ref parameter.
>
> Everything will work if you declare a const ~this(), but that seems a
> little nonsensical. And you cannot have both const and non-const ~this().
>
> I'm a bit uncertain as to how this is all supposed to work.
> (1) Should temporaries be allowed to be passed as 'const ref'?
> (2) If a struct has a destructor, should it be passable as a const
> parameter? And if so, should the destructor be called?

This is a delicate matter that clearly needs a solution. Pass of 
temporaries by const ref was a huge mistake of C++ that it has paid 
dearly for and required the introduction of a large complication, the 
rvalue references feature, to just undo the effects of that mistake. So 
I don't think we should allow that.

Regarding destructors, for every constructed object ever there must be a 
corresponding destructor call. One issue that has been a matter of 
debate in C++ has been the fact that any object becomes "deconstified" 
during destruction. The oddest consequence of that rule is that in C++ 
you can delete a pointer to a const object:

// C++ code
class A { ... };
void fun(const A* p) { delete p; /* fine */ }

There has been a lot of opposition. const is supposed to limit what you 
can do with that object, and the fact that you can't invoke certain 
methods or change members, but you can nuke the entire object, is quite 
nonintuitive (and leads to a lot of funny real-life comparisons such as 
"You can go out with my daughter, but no touching. Of course, you can 
shoot her if you so wish.")

In D, the rule must be inferred from D's immutability rules, which 
pretty much dictate that the destructor must be overloaded for non-const 
and const (and possibly invariant if the struct needs that).


Andrei