From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B77AD17C236 for ; Fri, 26 Jul 2024 13:43:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.70.40.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722001427; cv=none; b=SpKn4UzfxhkABcmNFuTMcflLYobCfum6tj+NY/TqXw+OJIM9BRblkc6N+ueEQ9dHlb9GQgm+LatThOsgXkCNuEtURkEZAC4okrbWwosAGzuHF6welS9gI8J0Li8KUkhBBK3sjjRJ9r/X2zi7xtv2eF8iqaluEpfQgF4W0gTm0+E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722001427; c=relaxed/simple; bh=LpmTpst9tCOw77A57JCy7v0ELdCC5+ZAdYNsqWRsD3A=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=g0agavYecbZ5rXY3vDKhqWkYWhqBKA9j9vj49xr9YQ8gNqVEdqNhTw/cCgi6gY8DxQ7iC2yAX0DeU20sIyW2RCoaFFXdYGtsmnGQGzSYl28qWmzUViewN7LbhUDeZeMeIp9pLJhHxuPpf9NrjY4ZinIFWW6GQPnKH/ZbMFKC18Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me; spf=pass smtp.mailfrom=proton.me; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b=OSB9SSV9; arc=none smtp.client-ip=185.70.40.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=proton.me header.i=@proton.me header.b="OSB9SSV9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1722001423; x=1722260623; bh=YGvFGgwYypuNV9H/Bzk9WCSdRPbec4gTm6JXzoCZIaU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=OSB9SSV9388drZ8Fu8+t9OWBxkDFtazQ9Ke0aq1EmH5uNneZdAbm73JXkR76jGXQq thMHYii0+768P+tRY8GykXzTW9s0iPum3ROcVPJYkCyBUxUp23T0L1i72JCE0bCpH5 CNpSoMETqu8/z+a3gCjDW2VBpewTvK4lB8UyfjcEePQTmPutQEU+kBD2VM7R90eQY7 xe5FJSzW+iB4oOuSogTcmvvAPDBh4vTIJakRrQ06qWKcJr4C+1KEdx701fkFKKMnnw M9zjdCY4OqcN4/N6mK4LcLHQ72CQ88ipMvPObzWRy6uAOslLbVDq4L8h8MtOf7kwM/ 1F33F74rytbzw== Date: Fri, 26 Jul 2024 13:43:38 +0000 To: Boqun Feng From: Benno Lossin Cc: Alice Ryhl , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Miguel Ojeda , Alex Gaynor , Wedson Almeida Filho , Gary Guo , =?utf-8?Q?Bj=C3=B6rn_Roy_Baron?= , Andreas Hindborg , Jonathan Corbet , Viresh Kumar , Danilo Krummrich , Trevor Gross , gregkh@linuxfoundation.org Subject: Re: [RFC PATCH] rust: types: Add explanation for ARef pattern Message-ID: In-Reply-To: References: <20240710032447.2161189-1-boqun.feng@gmail.com> Feedback-ID: 71780778:user:proton X-Pm-Message-ID: 978f8f08559271b0ce9f750c86bab903fa4f9c00 Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 25.07.24 22:29, Boqun Feng wrote: > On Thu, Jul 25, 2024 at 06:12:56PM +0000, Benno Lossin wrote: >> On 24.07.24 19:44, Boqun Feng wrote: >>> On Tue, Jul 23, 2024 at 11:14:29AM +0200, Alice Ryhl wrote: >>>>> +/// However `&Self` represents a reference to the object, and the li= fetime of the **reference** is >>>>> +/// known at compile-time. E.g. the `Foo::as_ref()` above. >>>>> +/// >>>>> +/// ## `impl Drop` of an `impl AlwaysRefCounted` should not touch th= e 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 { >>>>> ptr: NonNull, >>>>> _p: PhantomData, >>>>> -- >>>>> 2.45.2 >>>>> >>>> >>>> I think this is missing some basic information related to `&Self` -> >>>> `ARef` conversions. We should explain that these conversions are >>>> possible, and that you usually don't want `raw_ptr` -> `ARef` to >>>> increment the refcount - instead provide a `raw_ptr` -> `&Self` and >>>> convert the `&Self` to `ARef`. >>>> >>> >>> I could be more explicit on this, but could there be a case where a `T` >>> only wants to return `ARef` as a public API? In other words, the >>> author of `T` doesn't want to expose an `-> &T` function, therefore a >>> `-> ARef` function makes more sense? If all the users of `T` want to >>> operate on an `ARef` other than `&T`, I think it makes sense, right? >> >> You can always get a `&T` from `ARef`, since it implements `Deref`. >> >=20 > Yeah, but this is unrelated. I was talking about that API providers can > decide whether they want to only provide a `raw_ptr` -> `ARef` if > they don't need to provide a `raw_ptr` -> `&Self`. >=20 >>> Overall, I feel like we don't necessarily make a preference between >>> `->&Self` and `->ARef` functions here, since it's up to the users= ' >>> design? >> >> I would argue that there should be a clear preference for functions >> returning `&Self` when possible (ie there is a parameter that the >=20 > If "possible" also means there's going to be `raw_ptr` -> `&Self` > function (as the same publicity level) anyway, then agreed. In other > words, if the users only need the `raw_ptr` -> `ARef` > functionality, we don't want to force people to provide a `raw_ptr` -> > `&Self` just because, right? I see... I am having a hard time coming up with an example where users would exclusively want `ARef` though... What do you have in mind? Normally types wrapped by `ARef` have `&self` methods. Cheers, Benno