Destructors, const structs, and opEquals

[Andrei Alexandrescu]

On 12/4/10 9:23 AM, Don wrote:
> 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.

I think it should be as follows:

bool opEquals(auto ref inout Tuple rhs) inout {
   foreach (i, T; Types) {
     if (this[i] != rhs[i]) return false;
   }
   return true;
}

It looks a bit alembicated but let's not forget that Tuple is supposed 
to be very flexible and to do a lot of things.

> How can opEquals be defined in a way that it works for structs with
> destructors, and also with rvalues?

"auto ref" should be used whenever you want to accept both a value and 
an rvalue. For structs with destructors see my other post in this thread.

Unfortunately, "auto ref" is currently implemented wrongly due to a 
misunderstanding between Walter and myself. I meant it as a relaxation 
of binding rules, i.e. "I'm fine with either an rvalue or an lvalue". He 
thought it's all about generating two template instantiations. In fact 
auto ref should work when there's no template in sight.

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

Why? It makes perfect sense to qualify the destructor the same way as 
the originating constructor. It has been a serious limitation of C++ 
that you couldn't tell during either construction or destruction that a 
const object was being built/destroyed.

One issue with D's const is that people expect to use it most 
everywhere, much like C++'s const. One thing that I understood early on 
was that D's const provides much stronger guarantees than C++'s, and as 
a direct consequence it is more constrained and is usable less often.

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

Yes. Any object created will also be destroyed, regardless of qualifiers.

> Seems to me that the natural rule would be, that the creator is
> responsible for destruction.

That rule is roughly C++'s and has an issue that D fixes (in my mind; 
the implementation is not 100% there yet). Exact issue is discussed below.

> 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?

What's wrong with it is it consistently leads to suboptimal code, which 
has created a hecatomb of problems for C++ (even the very carefully 
conceived rvalue references feature, for all its size and might, is 
unable to fix them all).

The caller should create the copy and pass the responsibility of 
destroying to the callee. This is because oftentimes the actual object 
destroyed is not the same object that was constructed. You see those 
trailing calls ~__tmp1, ~__tmp2 at the end of your code? They are a tin 
cat stuck to code's tail.


Andrei