On Tue, Jul 23, 2024 at 11:14:29AM +0200, Alice Ryhl wrote: [...] > > +/// ## `ARef<Self>` vs `&Self` > > +/// > > +/// For an `impl AlwaysRefCounted` type, `ARef<Self>` represents an owner of one reference count, > > +/// e.g. > > +/// > > +/// ```ignore > > +/// impl Foo { > > +/// /// Gets a ref-counted reference of [`Self`]. > > +/// /// > > +/// /// # Safety > > +/// /// > > +/// /// - `ptr` must be a valid pointer to `foo` with at least one reference count. > > +/// pub unsafe fn from_ptr(ptr: *mut foo) -> ARef<Self> { > > +/// // SAFETY: `ptr` is a valid pointer per function safety requirement. The cast is OK > > +/// // since `foo` is transparent to `Foo`. > > +/// // > > +/// // Note: `.into()` here increases the reference count, so the returned value has its own > > +/// // reference count. > > +/// unsafe { &*(ptr.cast::<Foo>()) }.into() So I did use the `&Self` -> `ARef<Self>` conversion here, > > +/// } > > +/// } > > +/// ``` > > +/// > > +/// Another function that returns an `ARef<Self>` but with a different semantics is > > +/// [`ARef::from_raw`]: it takes away the refcount of the input pointer, i.e. no refcount > > +/// incrementation inside the function. > > +/// and mentioned the difference between .into() and `ARef::from_raw()`. > > +/// However `&Self` represents a reference to the object, and the lifetime of the **reference** is > > +/// known at compile-time. E.g. the `Foo::as_ref()` above. > > +/// > > +/// ## `impl Drop` of an `impl AlwaysRefCounted` should not touch the refcount > > +/// > > +/// [`ARef`] descreases the refcount automatically (in [`ARef::drop`]) when it goes out of the > > +/// scope, therefore there's no need to `impl Drop` for the type of objects (e.g. `Foo`) to decrease > > +/// the refcount. > > pub struct ARef<T: AlwaysRefCounted> { > > ptr: NonNull<T>, > > _p: PhantomData<T>, > > -- > > 2.45.2 > > > > I think this is missing some basic information related to `&Self` -> > `ARef<Self>` conversions. We should explain that these conversions are > possible, and that you usually don't want `raw_ptr` -> `ARef<Self>` to > increment the refcount - instead provide a `raw_ptr` -> `&Self` and > convert the `&Self` to `ARef<Self>`. > I could be more explicit on this, but could there be a case where a `T` only wants to return `ARef<T>` as a public API? In other words, the author of `T` doesn't want to expose an `-> &T` function, therefore a `-> ARef<T>` function makes more sense? If all the users of `T` want to operate on an `ARef<T>` other than `&T`, I think it makes sense, right? Overall, I feel like we don't necessarily make a preference between `->&Self` and `->ARef<Self>` functions here, since it's up to the users' design? Regards, Boqun > Alice