Re: Possible RFC: UniqueInterface that throws exception at refcount > 1

On 11 July 2020 22:47:21 BST, "Olle Härstedt" <olleharstedt@gmail.com> wrote: >You're misunderstanding. :) Yes, it should be shared, but not with the >same access level as the owner. If a dependent class closes the >connection it will cause spooky-action-at-a-distance somewhere else in >the program. I think that particular example is solved adequately by destructors: if you know you hold the last reference to an object, you can unset() that reference and the destructor will fire. You'd only need the ability to "unfreeze" an object if you were going to mutate it and then carry on using it. > Sorry, it's related to refcount as ownership checking I still don't think those concepts map well. If you store two references to an object in an array, and then unset one of them at random, does it make sense to say the remaining reference "owns" that value, because the object now has a refcount of one? As I understand it, ownership in Rust implies not just the *right* to free something, but the *obligation* to do so. That only works if ownership is explicitly assigned, rather than being a side effect of other references being released. Thinking about destructors, a better description of how PHP currently works might be that the owner of an object is the object itself, and the refcount is a count of how many times it has been borrowed. So once the constructor completes, all we can say is that there is at least one "borrowed" reference somewhere in the code; once that stops being true, the "owner" is notified, and runs the code in the destructor. You could create a wrapper object and have a way to check that its destructor had been called - anything from setting a global variable to holding a WeakRef and calling its valid() method - but if something *does* hold onto a reference, there's not much you can do about it. I can't think of a scenario where the code that wants to "own" the object wouldn't end up equivalent to either full immutability (don't mutate it after initialisation because you can't guarantee yours is the only reference) or an optimised copy-on-write (mutate if you happen to have the last reference, otherwise clone). It would be better for the language to implement those in a user-friendly way than exposing the implementation details of refcounting. Regards, -- Rowan Tommins [IMSoP]