From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 F21143603C8 for ; Fri, 20 Mar 2026 10:04:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774001049; cv=none; b=KcBByKttiNliVBKkstSQB/RE1IqOrUme0dfuCvA2C4ri0dwIY7P7cCZI/yAmI7Wnb2wjJ2iIC53y6EusVMWb/f3gQoEhR45RaR9Q7ybAr/epxaiHytZnZmQ6Us+ZcjyUEOBQnwkKHss9hp6y0hqQjmrRiJrbEqCnCZwGs6QpUhI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774001049; c=relaxed/simple; bh=pUZM51P+s35keGbJ3K0YOR/u2sXloBZ/B/2/e0lWbIs=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=HKyBenNQpqiNhT7FubwT9ORcT55MtSHWLQPf1YI6mIncM6IyLDaAxXMjQaB29Ts913wBM1h0w6X5cJWo8ErH/wtMXg+LCJCTHuODqojZAMKYGmuPGT9FyvrLBuPSg9ZyIHRJrP0s1RnAOKJ1bINcL6SnjRRH76gcvyrMuLA0CNo= 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=WvzEroQC; arc=none smtp.client-ip=209.85.214.174 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="WvzEroQC" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2a7a9b8ed69so23407495ad.2 for ; Fri, 20 Mar 2026 03:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774001047; x=1774605847; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Izdm/7D68g40rNesT50ueXh6Akh0cFui4OgMPqSoSys=; b=WvzEroQCp8epzquEDUs7lp6ynirNJHoRH6NqQsIDOIgEoiltTCwg8n9gIr7OYVVM/v CZ8iD8GRt/Ciy+oewHB5qICWoOHTZiJAv/LkSeMkMcX2QOvuNJJtaphS2bYnu/LbXR0Y /wSwlFM60dp2jDt9OueNtt1bL6uZErnqLw0SkwxrMjiLQ37oGwoHdVv4qPvJiVRWu4T5 o67ZZML4N/bLHXWejn+uxuKsPYJ6JjdSJIkd0d9SPqKtNmpsrGhLQG50ZdEe642yJc9l BeaIm0gF7Dh2+8KK3Do6DNlaTQayhD4PHPBwjAYMGmBltXGWVp671GdW7i0mJ4zwnyOy TScA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774001047; x=1774605847; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=Izdm/7D68g40rNesT50ueXh6Akh0cFui4OgMPqSoSys=; b=ReP1lwtzQ2qdXiKrkdMJ5GBC4v2lCT8qa/k8CT1aGhP+RNoRHeZJAGKmI8j1OpfScC za21QpXDXN0X+znQCTSaxc2ubYhGO2xQyFEQ13rXNKLDzwSg2kqedQI5ZQolZpO4i5Rk 7vkcz+Sy8R5bBfE+Zs7Gs9kWaORev0ublMgIsd9U/oqUq2YEsNaFToePWtI50sJ10je/ 8zAlo+KQ0kyXIvfAdcfQx+Sb7+K0m59a/MImKRSblKj/24kv/jY7qsIPWBegyaEb9KBM nUf/Y+BFvA6MFaP1C4ZdnpneQixfxwOVsbXePMsMV2EWBoy2082sJ6pVxrJKK+DWzCwe d1LA== X-Forwarded-Encrypted: i=1; AJvYcCVWNmS9o42NbppVwJQdTRy3FilGQ8FHUlmbdmzGGNFsFjfDzcdAXUyhWYrqzdqDV0Z/jvr5YF/rY5e5yVM=@vger.kernel.org X-Gm-Message-State: AOJu0Yzs4Ysr0JL25hPgXDyOetOmuB/+lZevGx2D/Edv5zC7yqErKQyB mmXhQBOyTRjXHeT5JUuziMf9Byc8M9vLttp0iV3mmf/Q9rSZA9RcdAgofY+AOA== X-Gm-Gg: ATEYQzw3lxTLKww3ohgvC8cr4WOQzbxICulWwJU9OoZIYLRvVNgNZXZF4efX8XunzyP JirbmXVUzF4YlnuvaZTkI5RamrdYdUBTxDWg7lurik3+MGxwJKGtDqeBN7BlXMpliy1VJ08TRyr ndCgQG0hvlEgISicBUDRQ+4vjdEVLGJRoOq45KMS6l/26fjf1o08Y9ep2778vfcH+NY8yyZdOZJ 2sz8hLs/gxZh4aJmUo4q47DI0duZaHc2jNWAFokved+LoTmIMLUCJZWDS46GINLPIq9tgdPvJJc gmgY/8Xn78IqkUtwHZ4Sz1ImUoGVOKtBky/7VqMwOgJdJ1QljVR9Qzsj1cmDVBw+SWvMYXCytlM sUGbgZ6wkntu3Ip2UjjmUOZ7IuiShbRHg+ibQX9sFlVp/9gCL1l2VOcpsnyRqmEx1DHjNhjU+An 9gu5P2LKtNT+dYJnhGKw== X-Received: by 2002:a17:903:244b:b0:2b0:676d:973e with SMTP id d9443c01a7336-2b0827e3593mr22392635ad.46.1774001047271; Fri, 20 Mar 2026 03:04:07 -0700 (PDT) Received: from localhost ([112.149.32.52]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2b083516400sm16756525ad.11.2026.03.20.03.04.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 20 Mar 2026 03:04:06 -0700 (PDT) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 20 Mar 2026 19:04:01 +0900 Message-Id: Cc: , "Miguel Ojeda" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Alice Ryhl" , "Trevor Gross" , "Danilo Krummrich" , , , Subject: Re: [PATCH v5 0/4] rust: add `TryFrom` and `Into` derive macros From: "Jesung Yang" To: "Alexandre Courbot" , "Jesung Yang via B4 Relay" X-Mailer: aerc 0.21.0 References: <20260129-try-from-into-macro-v5-0-dd011008118c@gmail.com> In-Reply-To: Apologies for the delay. On Sat Feb 28, 2026 at 2:31 PM KST, Alexandre Courbot wrote: [...] > FWIW I have converted nova-core to use this, and this results in -200LoC > delta. Obviously I like this very much. :) > > A few pieces of feedback for things I noticed while doing the > conversion: > > - Very often we need to convert a type from and into the same primitive. > Not having to repeat the same thing in `#[try_from(foo)]` and > `#[into(foo)]` for these cases would be nice. I think I can add a common attribute that works for both `TryFrom` and `Into`, e.g. `#[convert(foo)]`. > - In some rare cases, we want to convert an enum with 4 variants into > e.g. a `Bounded`. This can be done using a `From` > implementation, and that's what the register macro expects. These > cases are not covered by the current macro (they are few however). I think you can just do the following?: #[derive(Into)] #[into(Bounded)] enum Enum { A, B, C, D, } let a =3D Bounded::::from(Enum::A); // or let a: Bounded =3D Enum::A.into(); This works because `Into` actually generates the `From` implementation for `Bounded`. > - When converting from/into boundeds, the number of used bits is the > only thing that counts - the backing type (u8, u32, ...) is > irrelevant. I thought it would be cool to be able to have a generic > TryFrom/Into implementation that works irrespective of the backing > type, but as far as I can tell this would be difficult to achieve. > Just throwing the idea in case others are more inspired than I am. :) Yeah, it seems difficult to me as well since those macros need the full type information to generate the trait implementations. >> One last point: the current `Into` implementation relies on >> `Bounded::from_expr()`, which utilizes `build_assert!()`. So the >> expanded result looks roughly like this: >> >> impl From for Bounded { >> fn from(value: Enum) -> Bounded { >> // Compile-time assertions to guarantee `value` fits within >> // `u8` (Omitted) >> >> Bounded::::from_expr(value as u8) >> } >> } >> >> After some experimentation, it appears that the compiler correctly >> optimizes out the assertion if (and only if) the `Bounded` type covers >> all enum discriminants, though I'm not 100% certain of this behavior in >> all cases. Can we approach this better? > > I think you should also be able to have a match arm for all variants and > call the `Bounded::new` const method - hopefully the compiler will > optimize that as well. That or rely on unsafe code and a (hypothetical) > `new_unchecked` constructor for Bounded, since the macro can infer that > its invariants are respected. This looks much better. Thanks for the idea! I'll update the implementation based on your feedback within this week, but I'd like to ping Benno first to check whether he's satisfied with this v5 before I send those new changes. Thanks for your patience. Best regards, Jesung