From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [45.144.208.40]) by lore.proxmox.com (Postfix) with ESMTPS id F3C991FF0B2 for ; Mon, 24 Aug 2026 15:13:36 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id C6F5D215CC; Mon, 24 Aug 2026 15:13:36 +0200 (CEST) Content-Type: text/plain; charset=UTF-8 Date: Mon, 24 Aug 2026 15:13:33 +0200 Message-Id: Subject: Re: [PATCH proxmox 03/20] api-macro: support shared state extraction type From: "Lukas Wagner" To: "Robert Obkircher" , "Lukas Wagner" Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20260817125727.454039-1-l.wagner@proxmox.com> <20260817125727.454039-4-l.wagner@proxmox.com> <178732075530.242959.9352845385667795142.b4-review@b4> In-Reply-To: <178732075530.242959.9352845385667795142.b4-review@b4> X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1787577183936 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.661 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: V4COGBBQVLWVZFETHCL46UVGPOANAJIO X-Message-ID-Hash: V4COGBBQVLWVZFETHCL46UVGPOANAJIO X-MailFrom: l.wagner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: pdm-devel@lists.proxmox.com X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri Aug 21, 2026 at 3:59 PM CEST, Robert Obkircher wrote: >> The State newtype wraps values that come from the registry, which >> allows telling them apart from regular API parameters. The API macro >> recognizes them in API handler signatures and looks them up in the >> shared state registry of the RpcEnvironment, instead of deserializing >> them from the request parameters. That way a handler declares its >> dependencies on application state in its signature and does not have to >> access the environment by hand. > > Another way of telling them appart would be to use an attribute. It's > slightly more verbose by itself, but it would make it easier to pass > the type by value: > > e.g. > fn a(#[state] foo: Foo) { f(foo) } > fn b(foo: State) { f(*foo) } The attribute looks interesting, I might give that a try! Thanks! It would save devs from having to use .into_inner if they want a `Foo` instead of `&Foo` > > Or simply removing the wrapper from the proc macro output could work as > well, but that might be confusing. Yeah, the only reason why `State` exist in the first place is to make it easier to distinguish API parameters from injected state. It's mostly there for clarity for the developer, although it also makes the implementation of the API Macro a bit simpler. > > The wrapper is totally fine though, I just wanted to mention this for > completeness.