pre-RFC: the Destruct trait

[earthengine]

@Darsstar

I feel the final RFC, and preferably this pre-RFC too, should explain how Destruct would interact with the Pin API and the invariants it guarantees. Pin and Drop already interact badly, but we are stuck with a Drop::drop(&mut self) instead of Drop::drop(self: Pin<&mut Self>) .

A good point. I believe Drop::drop(self: Pin<&mut Self>) is the right constraint, as it implies exactly what Drop + Destruct implies for drop. However as this is suppose to be a 100% backward compatible RFC, let us fix it afterwards.

@Ixrec

elieve that because this pre-RFC also says:

earthengine:

@Ixrec

I think the alleged benefit is that this proposal makes it possible to move out of self during drop() without unsafe code, but I’m not sure I even believe that because this pre-RFC also says:

The other benefit I want to have is to allow by-move pattern match on Drop types.

@Ixrec

which sounds like it’s merely replacing unsafe code with the possibility of UB in safe code.

Oh this is not what I mean. I see someone already spotted out that drop is already not allowing partial move, so maybe I was wrong and I need to adjust it.

It would mean we don't need to adjust fn drop(&mut self) to fn drop(self: Pin<'_, Self>)? Because, Pin only means not moving out until drop, and this is true in both signatures.

@Centril

If UB is prevented, how much is prevented? In other words, how prevalent is the problem, how easy is it to get wrong and cause UB?

For this part, I am correcting myself.

@Centril

Can the attribute be generalized / be useful generally? or will it only revolve around Drop ?

This is exactly what I proposed in another RFC. In sort, I want the attribute to be generally available, if people like to use. And because it is a restriction on what code can be written, it can hardly be abused. However, I didn't see practical use of this attribute except in Drop context.

@CAD97

Partial moves are already disallowed in Drop::drop . Because you have &mut self , you can’t move from self , only modify. (That’s the whole reason for the proposal).

Thanks for the clarification. I will update when I confidently understand this.

@CAD97

Please clarify why this behavior of Drop + Destruct types allowing a structural by-move-out match outside of the Destruct implementation is desirable. I (still) think this is more surprising than useful.

I would update the text later. But right now let me explain it a bit. In "things allowed" part I listed 1. relax E0509: by-move pattern match on Drop types; and 2. full control on dropping logic without unsafe code.

But this two things are somehow contradicting: custom by-move match means different logics other than the one specified by Destruct can be specified, and so in this case, there will be different ways to destruct the object! The programmer then have to let the object user to decide which way they want to destruct.

What all these mean? If you have an object that the destruction order is irrelevant, but you need to specify RAII behavior, you will write Drop. Then if you want by-move match, you can derive Destruct.

If on the other hand, you want to specify the destruction order, you would better keep all fields private and so people cannot do by-move matches. And then your Destruct will specify the exact order of destruction. Even in this case, the flexibility of by-move match still allows you to define a method to destruct the object in a different way.