Re: [PATCH 1/2] rust: num: casts: replace const type narrowing methods with a macro
From: Gary Guo
Date: Tue Aug 25 2026 - 10:30:44 EST
On Tue Aug 25, 2026 at 3:02 PM BST, Danilo Krummrich wrote:
> On Tue Aug 25, 2026 at 10:25 AM CEST, Miguel Ojeda wrote:
>> On Tue, Aug 25, 2026 at 4:45 AM Alexandre Courbot <acourbot@xxxxxxxxxx> wrote:
>>>
>>> const DMA_LEN: u32 = casts::usize_into_u32::<{ MEM_BLOCK_ALIGNMENT }>();
>>>
>>> into
>>>
>>> const DMA_LEN: u32 = casts::const_as!(MEM_BLOCK_ALIGNMENT => u32);
>>
>> 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.
>
> As mentioned in [1], I also think it's not great, but I also don't mind having
> it as is for now.
>
> I guess my main question is how we expect this to evolve. How do we want this to
> look like once we have things like const function arguments or const trait
> methods? Is it worth getting back and forth on a macro solution with this in
> mind?
It's easier to evolve with macros. Once we have const trait, the cast becomes
const { from_expr.try_into().unwrap() }
or
const { TargetType::try_from(from_expr).unwrap() }
which we can just change the macro to expand to.
That said, whether we want raw
const { u32::try_from(MEM_BLOCK_ALIGNMENT).unwrap() }
vs
const_as!(MEM_BLOCK_ALIGNMENT => u32)
is a different question. We probably can have a `const_try!()` macro that
unwraps both `Option` and `Result` in const eval so write
const_try!(u32::try_from(MEM_BLOCK_ALIGNMENT))
or
const_try!(MEM_BLOCK_ALIGNMENT.try_into())
Regardless, the "ultimate state" is not going to be turbofish and would take a
form of expression syntax wrapped in const block.
Best,
Gary