drop could take self by-value, and allow early destruction

[thestinger]

There's currently a util::ignore function that consumes a value to destroy it early.

It would be nicer the if Drop trait's drop method took self by value and could be called early, which would require some compiler magic to avoid an infinite destruction cycle in the drop method. This would also allow drop to move out of self, which is potentially useful.

[erickt]

Now that we can move out of methods, could we just change the finalize method to fn finalize(self)? That'd save us from having to implement another trait.

[thestinger]

@erickt: that was actually the original idea, and the idea of doing it with a trait actually came later to avoid needing compiler changes since I hadn't considered that it would result in a destruction cycle. However, it turns out there's already util::ignore which is good enough as a single way to do this, but would still be nice if finalize just took self by-value. Going to update the bug report with that in mind.

[brson]

I was thinking this would be useful as well, but I don't know how it can work. During destruction the allocator essentially 'owns' the value and by passing self to finalize it is giving up ownership. This would possibly be ok if the value was trapped in the finalizer and was sure to go out of scope, but the finalizer is also free to send it to another task, or if self is ~str to pass it to fail. There may be other ways it could escape as well.

[nikomatsakis]

I do think that the finalizer should take self "by value". @brson I'm not quite sure what you think would be wrong with that.

[nikomatsakis]

Nominating for milestone 2.

[brson]

We discussed at the work week why by-value finalizers are ok and you convinced me at the time, but yet again I don't understand how that works.

[nikomatsakis]

Short version: what we call "by-value" really just means that ownership of the contents is transferred to the callee. So the callee is responsible for freeing the contents, basically. In most cases, the value of a "by-value" parameter is still passed by pointer, it's just that we create a value on our stack and give a pointer to the callee. They are responsible then to free the data in that stack region, we don't free its contents. This seems to match destructors perfectly, if you generalize "stack region" to "memory region".

[brson]

It isn't true though that the finalize is responsible for freeing the contents. The compiler generates code to free the contents after finalize finishes. What if finalize moves self somewhere else?

[nikomatsakis]

Yes, today the compiler generates the code to free the contents, but that's precisely what I propose to change. Instead, the contents would be freed (or sent, or moved) by the destructor, just as with any other by-value argument. I don't see a problem with the fact that the destructor can send or move self, in fact, it's one of the motivations for me.

[graydon]

oops, closed by accident.