From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 405A71FF0AA for ; Fri, 21 Aug 2026 15:59:34 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 8265721598; Fri, 21 Aug 2026 15:59:33 +0200 (CEST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Subject: Re: [PATCH proxmox 03/20] api-macro: support shared state extraction type From: Robert Obkircher To: Lukas Wagner In-Reply-To: <20260817125727.454039-4-l.wagner@proxmox.com> References: <20260817125727.454039-1-l.wagner@proxmox.com> <20260817125727.454039-4-l.wagner@proxmox.com> Date: Fri, 21 Aug 2026 15:59:15 +0200 Message-Id: <178732075530.242959.9352845385667795142.b4-review@b4> X-Mailer: b4 0.16-dev X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1787320743155 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.675 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: ZVVKYDODBEXA2JGLHBVGBFTN5OX2RBPP X-Message-ID-Hash: ZVVKYDODBEXA2JGLHBVGBFTN5OX2RBPP X-MailFrom: r.obkircher@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: > 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) } Or simply removing the wrapper from the proc macro output could work as well, but that might be confusing. The wrapper is totally fine though, I just wanted to mention this for completeness. -- Robert Obkircher