Re: [PATCH 1/2] rust: num: casts: replace const type narrowing methods with a macro

["Gary Guo" <gary@garyguo.net>]

On Tue Aug 25, 2026 at 9:25 AM BST, Miguel Ojeda wrote:
> On Tue, Aug 25, 2026 at 4:45 AM Alexandre Courbot <acourbot@nvidia.com> wrote:
>>
>>     const DMA_LEN: u32 = casts::usize_into_u32::<{ MEM_BLOCK_ALIGNMENT }>();
>>
>> into
>>
>>     const DMA_LEN: u32 = casts::const_as!(MEM_BLOCK_ALIGNMENT => u32);
>
> Hmm... I have been following the discussion and listening to both
> sides of the argument.
>
> The macro interface looks obvious enough, and we could consider adding
> it to the prelude.
>
> Having said that, macros have a cost too when they introduce new
> "syntax", so since the beginning we have tried to minimize their use
> to where we feel is worth it.
>
> The former line above is not perfect by any means, but it is
> nevertheless syntax that one needs to already know. Personally
> speaking, I don't care if I have to write the former or the latter, to
> be honest, so I am OK with both ways. But I worked with C++ TMP in the
> past, so my eyes may be desensitized. :)

What I have issue with is to have things that do not belong to the type system
in const generics. Expressive power is really limited in it, so any
expressions involving generic parameter, for example, won't be usable inside the
turbofish. It also doesn't work for custom types, so the approach does not
generalize.

The type/value distinction is one of the biggest change I made to `const {}`
implementation, many features of `const {}` is possible (e.g. reference to
generic parameter freely) precisely because values don't flow to the type
system.

Yes const_generic_exprs is being worked on and it'll blur the line between type
and values. But we're not there yet, and I think it still worth having a clear
distinction and we don't put things that don't need to be in the type system
there.

>
> Apart from readability concerns, we are saving here a few characters;
> getting possibly different codegen (forced textual inline), and maybe
> having better or worse compiler-side time/memory/disk numbers. Is that
> about it? It would be good to measure any actual difference.

The macros are much better than functions in my opinion, because it compose well
with the type system. The all "foo_as_bar" methods also compose poorly with type
alias, where this macro doesn't have that issue. Also, values no longer end up
in the type system to begin with.

>
> What I wouldn't want is a raw `as`, because the point of the saga we
> started a long time ago is to introduce better tools that allow us to
> get rid of the almighty `as` into weaker (i.e. safer) options, even if
> some uses of `as` may be "obviously right".

I think that is rather a linting issue, not something that warrants extra code
in kernel. We have been requesting some extra clippy features and I think that
is the correct way to go, not add a ton of methods and macros. Yes, it wasn't
moving on clippy end, but I could add a feature to klint instead?

Do you think we still need all these extra function and macros if we
can get clippy (or klint) to enforce CAST comments?

I can imagine the following rules that would practically solve all the footgun
of `as` numerical casts without having to use awkward syntax:

* widening casts are allowed
* narrowing casts is disallowed unless CAST comment exists, except where its
  value is constant and truncation does not happen.

Best,
Gary