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

On Tue Aug 25, 2026 at 5:25 PM JST, Miguel Ojeda wrote:
> On Tue, Aug 25, 2026 at 4:45 AM Alexandre Courbot <[email protected]> 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.

Ideally we could write it like `const_as!(MEM_BLOCK_ALIGNMENT as u32)`
but unfortunately declarative macros won't let us do that. That being
said there might be a better syntax.

>
> 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. :)

I also don't mind the turbofish. Actually I like how it unambiguously
signals that something is evaluated at build time. But in this case the
macro seems justified to me as we are trading 9 different
macro-generated declarations for a single one that is much more obvious
to discover and use. The declaration site of the previous helpers was a
paste-party that is difficult to read and edit.

`const_as!` also has the benefit that it can probably survive the
`TryFrom` constification, as I don't believe we will want users to
sprinkle unwraps in their const blocks.

Another bonus, especially if we add it to the prelude: `const_as!` also
covers expanding conversions, so we can also replace many of the e.g.
`u8_as_u32` calls with it, with `FromSafeCast` covering the non-const
cases. This leaves the `*_as_*` family of functions only needed for
const fns that need to expand a parameter, for which there are no
in-tree users at the moment.

>
> 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.

I don't expect much difference between the two, but will try to gather
some metrics for v2.