Destructors, const structs, and opEquals

[Don]

Andrei Alexandrescu wrote:
> 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.

Fine, but try to implement a generic type which supports ==.
For example, Tuple in std.typecons.
The only reason that many of the Tuple unit tests pass is that opEquals 
never gets instantiated.
How can opEquals be defined in a way that it works for structs with 
destructors, and also with rvalues?


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

This scares me. I can see a danger of making structs with destructors 
practically unusable.

Some unprocessed thoughts are below.

Who calls postblit? I think that if you can make a clone of a const 
object, you should also be able to destroy that clone.

Seems to me that the natural rule would be, that the creator is 
responsible for destruction. This would require that, for example, given 
code like this:

const(S) foo(const(S) x) { return x; }

inside foo, a non-const S is created, blitted with x, then postblit is 
called on it, then it is returned as const. On return, the original x is 
destroyed if it was a temporary. Otherwise, it gets called at the end of 
its scope.

Eg,

const w = foo(foo( S(2) ));

would be translated into:
const w = (foo( S __tmp1 = S(2),  const(S) __tmp2 = foo(__tmp1), 
~__tmp1, __tmp2), ~__tmp2);


Has this sort of idea been explored? Is there something wrong with it?