From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 66B9426A1AC; Tue, 4 Nov 2025 20:22:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762287723; cv=none; b=DHpwZCjX5eyc7aKKd/synujrqtiAINOxA1OvGbySy3XqowYlS4/rYe+LRDDUHWw/loDWdm3bO/KzmKv8agmFEo/Vfdeajyykt9+5/maasPTTYb4NxFy0DLu9XMfjDeo1/FS0Qyiea9NSvcWGRmYVlXt/hqdmc4qlf59WGmTLHa8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762287723; c=relaxed/simple; bh=RvBDaup8WpSALz42fvH5hCxQIBOpv+Q/H5aOOBTmmN0=; h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:To:From: References:In-Reply-To; b=ErSRVA/bqd4VbWw5TbfVeKXPBNucoEVWPSwPCDq6mh+RgqrNDK4Jzg4/0L/H3lrPBOdHr7WG09zYpGCJQBP2vg2ZltHW5fCfip+LT5qZYIJ4CMeHXbggXFMHaKbnY//Daej3jhgjTY8+JESQfhL+gtkjoMM4ZnFB4bWbdQUOySg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XHvpeYQM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XHvpeYQM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D47CC4CEF7; Tue, 4 Nov 2025 20:21:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762287722; bh=RvBDaup8WpSALz42fvH5hCxQIBOpv+Q/H5aOOBTmmN0=; h=Date:Subject:Cc:To:From:References:In-Reply-To:From; b=XHvpeYQMvHCyL1EF0nPWxsOStmqYk384hVQ25l5zcWWp0z7O5RvzLl6xo7Lh20mch YKstnnFu2AbWQEp29ii5RObFIAQCtW8DsJGbETOAb5ayElVwf6Ub54IZ+fm6qM0dk1 btEG/Sibb3lI6M8xRQ5nGpe8KVGkTIYba7QDpgZFpAqunBlj/ZhXy842HzhbtlZzdB zIFMS9uzbT0EBroqveGuZ9iTBIQ6x08JlSRLQi3WCxn/CTlc0xVW9TalMRWjt7omW9 KfGvIOHH36R7IN4fZoHYr9PfkQaFjZtBxGUEqYDDEZebuCCqBNra7nVags0KOkQEkN gjjT2ZYaYI3/A== Precedence: bulk X-Mailing-List: rust-for-linux@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: Tue, 04 Nov 2025 21:21:58 +0100 Message-Id: Subject: Re: [PATCH 1/2] rust: add BitInt integer wrapping type Cc: "Alexandre Courbot" , "Alice Ryhl" , "Miguel Ojeda" , "Joel Fernandes" , "Jesung Yang" , "Boqun Feng" , "Gary Guo" , =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= , "Benno Lossin" , "Andreas Hindborg" , "Trevor Gross" , , To: "Yury Norov" From: "Danilo Krummrich" References: <20251031-bounded_ints-v1-0-e2dbcd8fda71@nvidia.com> <20251031-bounded_ints-v1-1-e2dbcd8fda71@nvidia.com> In-Reply-To: On Tue Nov 4, 2025 at 8:30 PM CET, Yury Norov wrote: > You switched name to BitInt, but still think about it as an object, Note that in Rust even "real" primitives have a strong object character, th= ey have lots of methods, trait implementation and associated constants [1]. You can even implement your own custom traits for a primitive type in Rust. [1] https://rust.docs.kernel.org/core/primitive.u32.html > and that brought all the confusion in my mind. Maybe switch back to > BoundedInt then to avoid this confusion? If you find it lengthy, > probably LimInt or simply Lint will be better for you. In another thread Alex proposed Bounded, because it follows the naming sche= me of other existing numeric types in Rust, e.g. NonZero [2]. [2] https://rust.docs.kernel.org/core/num/struct.NonZero.html > Looking at how good rust macros work to implement bitfields, I thought > that they will be able to mimic native types just as well. I assume you mean primitive types. If so, I think there isn't too much we c= an't do (e.g. literal syntax would be nice) with BitInt (or Bounded) that primit= ives can do. Especially when we consider the strong object character of "real" R= ust primitives. > With that in mind, I think that bounded integers are a bit out of > scope of basic bit operations, and probably I'm not a right person > to maintain them neither in Rust, nor in C. I think it's fair to consider this kind of type as core Rust infrastructure= . Maybe a RUST [NUMERICS] entry would make sense? You could be a reviewer. :)