From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B31217577; Fri, 26 Jul 2024 15:15:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722006934; cv=none; b=pnneFb3+iwgr/6Snt58hVp2xnrHvdnFsb0U3wZfGP3ItsmmVIpSAFRg4sBCHc7LPfTBkK6Ky4va4K8SMiRr0QjPSNbJ/Yvt44PSrUpXtivfnapxqr+ID1giexeykLDgmOSUopfGCjilxIZE0hYrphER7iLTw6QT4XgaVsb+yAxc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1722006934; c=relaxed/simple; bh=OsJJCaPxrl7RDPderqUC/MqhFU212Lp96yDsuIjk7RU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kq5vhDVwzvRwWSJWADaYfyUjLrE6+v6LOmVguNmc8/EVfn0z4MEE9/dl8h/+ZGb8UYxFwx/VnzYEP9o4fASiFelpPTbNtfa9MOQup0ah2mEZWd2ib5JSU7GweSsY0Auk+0S3vwIDNdz/abFXMdgFjVXGltenpJi3YgvDP75Inq8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=HDPKRqXM; arc=none smtp.client-ip=209.85.222.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HDPKRqXM" Received: by mail-qk1-f177.google.com with SMTP id af79cd13be357-79f19f19059so50927985a.0; Fri, 26 Jul 2024 08:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722006932; x=1722611732; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=UAAkqhXSNI4atUtqGzcRGBk007BlpzKq2aYaR6VMJOw=; b=HDPKRqXMj+FalAsccFJ3dKOVztyD6EcFNbHeqOvY6N0O6j9D4hOnDBvzxQuyZbZF7U p4tAyMeIbCdqOxMhTawrFR2teNnPWxekA+vRU8rNwjj7Z2eXVJQb8RGfhtwupmxddRSw K92SN1lqoSB87rpmQNdrDeV3BkHj0M6tXTJome2eCeoULe9BsVrZDA+wdY5WVA/JZ5/J j9pIXPwfRcAn25blEH36aJHeOuGWXHQ/zy6jsgtyrU2hjyFmxt9nTLk61dZsdkQf15+M hPpiGlTmqOOlQsK3YeKDW6oo5FpHeat8C7dT1VkmqrqzGalPeTOFzPCgDHcR6ofYO9xg 4roA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722006932; x=1722611732; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=UAAkqhXSNI4atUtqGzcRGBk007BlpzKq2aYaR6VMJOw=; b=q1lAiFrcwbYFly37x84Mx5GqXTzFJw8tLDkx5xfkLi2HtYPWw/wZixdWvptYL9D+H1 wwIjLlVABP48/7NHMEKSrqIGFsNVEpehkml9v4U7Qn6sjUKlNWxWU/b4Rei4fhN6DTIV WPXXeu+Nll+ZqMlpXMr2T6+EoyVhdTl1oZCyvQSeBwurS27xVOj87SOhS3V20QcVlVtI ihfDqLOrUXJDyhAwqatXVt4/KmV5OPAHTW0JVWgyUQDJcbS6T3rHyeodj0REJw7MN4Q/ qvU2GCU2urelcMnpqAGPyBuvCcpPHrRDnxZHIOJLVm3rXPIi1WM9MqNTOrlXXPspwMx1 d8WQ== X-Forwarded-Encrypted: i=1; AJvYcCXjdYbH3BO4DQ2rAyhTLDB16OKrUtNox5ngmrz/YUUyKuM0g9WuZ56ENvTbCwl8wEamYVjoDNKIqzyT6MiTFMdcWWt8DT9AUpptsgpwjvkSLESnbklxRJDO9IlHpzna8xcPheN1rdDmo2nn0ENfG370G7wHHIWeC78tAs2knwkWKtJ4dvaepNA= X-Gm-Message-State: AOJu0YxMKolkM2kKru7jFIN3/55NbkYocsc3aBJcFsm5c4E7iRwOBqNi qSI8cfCZ5aHFU3VmUWsSQ/zn28nQ1SN6XeRDFOXqaulM30vl97u+NbBFjA== X-Google-Smtp-Source: AGHT+IE980FiekM2UyfX6/SfodixEsD7/hGI43yrK9RBU92VtmfMY1jKBW1iRDH+IyE1R+z6/qIo4g== X-Received: by 2002:ad4:5cc2:0:b0:6b7:a8ef:e366 with SMTP id 6a1803df08f44-6bb5599f08cmr1480726d6.9.1722006931838; Fri, 26 Jul 2024 08:15:31 -0700 (PDT) Received: from fauth2-smtp.messagingengine.com (fauth2-smtp.messagingengine.com. [103.168.172.201]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6bb3f8d825esm17243136d6.29.2024.07.26.08.15.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jul 2024 08:15:31 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailfauth.nyi.internal (Postfix) with ESMTP id 10A6512000B1; Fri, 26 Jul 2024 11:15:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 26 Jul 2024 11:15:30 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrieehgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeeuohhquhhn ucfhvghnghcuoegsohhquhhnrdhfvghnghesghhmrghilhdrtghomheqnecuggftrfgrth htvghrnhephedugfduffffteeutddvheeuveelvdfhleelieevtdeguefhgeeuveeiudff iedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsg hoqhhunhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqieelvdeghedtieeg qddujeejkeehheehvddqsghoqhhunhdrfhgvnhhgpeepghhmrghilhdrtghomhesfhhigi hmvgdrnhgrmhgvpdhnsggprhgtphhtthhopedt X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 26 Jul 2024 11:15:29 -0400 (EDT) Date: Fri, 26 Jul 2024 08:15:27 -0700 From: Boqun Feng To: 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 , =?iso-8859-1?Q?Bj=F6rn?= 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: References: <20240710032447.2161189-1-boqun.feng@gmail.com> <81ceeca9-8ae5-4a82-9a46-f47767e60f75@proton.me> 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=us-ascii Content-Disposition: inline In-Reply-To: <81ceeca9-8ae5-4a82-9a46-f47767e60f75@proton.me> On Fri, Jul 26, 2024 at 02:42:36PM +0000, Benno Lossin wrote: > On 26.07.24 16:26, Boqun Feng wrote: > > On Fri, Jul 26, 2024 at 01:43:38PM +0000, Benno Lossin wrote: > > [...] > >>>> > >>>> You can always get a `&T` from `ARef`, since it implements `Deref`. > >>>> > >>> > >>> 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`. > >>> > >>>>> 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 > >>> > >>> 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. > >> > > > > Having `&self` methods doesn't mean the necessarity of a `raw_ptr` -> > > `&Self` function, for example, a `Foo` is wrapped as follow: > > > > struct Foo(Opaque); > > impl Foo { > > pub fn bar(&self) -> Bar { ... } > > pub unsafe fn get_foo(ptr: *mut foo) -> ARef { ... } > > } > > > > in this case, the abstration provider may not want user to get a > > `raw_ptr` -> `&Self` function, so no need to have it. > > I don't understand this, why would the abstraction provider do that? The Because no user really needs to convert a `raw_ptr` to a `&Self` whose lifetime is limited to a scope? Why do we provide a function if no one needs and the solely purpose is to just avoid providing another function? > user can already get a `&Foo` reference, so what's the harm having a > function supplying that directly? Getting a `&Foo` from a `ARef` is totally different than getting a `&Foo` from a pointer, right? And it's OK for an abstraction provider to want to avoid that. Another example that you may not want to provide a `-> &Self` function is: struct Foo(Opaque); impl Foo { pub fn bar(&self) -> Bar { ... } pub fn find_foo(idx: u32) -> ARef { ... } } in other words, you have a query function (idx -> *mut foo), and I think in this case, you would avoid `find_foo(idx: u32) -> &Foo`, right? Honestly, this discussion has been going to a rabit hole. I will mention and already mentioned the conversion `&Self` -> `ARef`. Leaving the preference part blank is fine to me, since if it's a good practice, then everybody will follow, otherwise, we are missing something here. Just trying to not make a descision for the users... Regards, Boqun > I get the argument that you need to always convert to `ARef` if users > only use that, but when `Foo` provides `&self` methods, you're not > required to have an `ARef`. > > --- > Cheers, > Benno >