The Next Steps for Single Ownership and RAII
Hm. That&#x27;s an interesting approach. The constraint reference encapsulating a ref counter is useful.<p>The &quot;destructors with parameters&quot; are interesting, but it&#x27;s not clear what prevents using the object (or trying to) after destroying it.<p>None of this seems to address locking. The trouble with locking in C-type languages is that the language has no idea what data the lock covers, and thus it&#x27;s hard to do an analysis for race conditions.<p><i>&quot;We made two tiny classes, Request and RequestHandle. Each had only a pointer to the other.  When one was destroyed, it would reach into the other to null out the pointer, thus severing the connection.&quot;</i><p>I&#x27;ve wanted something like that for Rust. Rust has problems with back references in trees and lists. There&#x27;s no safe way to do those. What you need for a back reference is something like what Vale has there. The back reference has to be a non-owning optional reference. The only allowed values which can be assigned to it are the owner and None. Changing the ownership implicitly sets it.<p>(This is one of the two big safety holes in Rust. The other is partially initializing an array. 
There&#x27;s no way to say to the language that &quot;0..N of this array are initalized&quot;. So &quot;Vec&quot; has to be unsafe. If both of those holes were plugged, there would be far fewer excuses for &quot;unsafe&quot;)