Re: [PATCH v4] rust: adding UniqueRefCounted and UniqueRef types

[Alice Ryhl]

On Wed, Mar 5, 2025 at 3:56 PM Oliver Mangold <oliver.mangold@xxxxx> wrote:
>
> Hi Alice,
>
> On 250305 1339, Alice Ryhl wrote:
> > On Wed, Mar 05, 2025 at 11:31:44AM +0000, Oliver Mangold wrote:
> >
> > > +impl<T: UniqueRefCounted> Deref for UniqueRef<T> {
> > > +    type Target = T;
> > > +
> > > +    fn deref(&self) -> &Self::Target {
> > > +        // SAFETY: The type invariants guarantee that the object is valid.
> > > +        unsafe { self.ptr.as_ref() }
> > > +    }
> > > +}
> >
> > What stops people from doing this?
> >
> > let my_unique: UniqueRef<T> = ...;
> > let my_ref: &T = &*my_unique;
> > let my_shared: ARef<T> = ARef::from(my_ref);
> >
> > Now it is no longer unique.
> >
> Oh, indeed. That's a serious problem. I see 2 options to deal with that:
>
> 1. remove ARef::From<&T>
>
> I checked the users of this, and it looks to me like there is rather
> a limited number and they are easy to fix by replacing the &T with ARef<T>.
> But I assume that wouldn't be welcome as it is intrusive nonetheless
> and of course there is ergonomic value in having the function around.

Definitely not an option. There are many users of this function that
are in the process of being upstreamed. The ability to go &T ->
ARef<T> is pretty fundamental for ARef.

> 2. add some new traits so implementers can opt in/out of that function.
>
> Basically one would have to pick if one wants to ARef::From<&T> or
> UniqueRef<T> for one's type.

I do think that you essentially need two structs to use this at all -
one for the shared and one for the unique case. Sounds pretty
unergonomic.

What is the use-case for these abstractions?

Alice