Re: [PATCH 1/2] rust: num: casts: replace const type narrowing methods with a macro
Miguel Ojeda <[email protected]>
| Newsgroups | org.kernel.vger.rust-for-linux,dev.linux.lists.nova-gpu,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CANiq72mYW0wQGzWRBvGqnatjysi4BnXBFLUpLPvrS0Q=JB2A0w@mail.gmail.com> |
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. 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. :) 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. 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". Cheers, Miguel