Re: [PATCH v5 21/38] rust: ptr: add const_align_up() and enable inline_const feature

[Alexandre Courbot]

On Thu Mar 5, 2026 at 11:05 PM JST, Gary Guo wrote:
> On Thu Mar 5, 2026 at 1:59 PM GMT, Alexandre Courbot wrote:
>> On Thu Mar 5, 2026 at 9:28 PM JST, Gary Guo wrote:
>>>>
>>>>   const TEST_ALIGN: usize = const_align_up::<256, 10>();
>>>>
>>>> This uses purely const asserts, but you have to work with two `usize`
>>>> arguments. The version below looks a bit nicer as it leverages the
>>>> power-of-two invariant of `Alignment`:
>>>>
>>>>   impl Alignment {
>>>>       const fn const_align_up(self, value: usize) -> usize {
>>>>           build_assert!(value <= usize::MAX - !self.mask());
>>>>
>>>>           (value + !self.mask()) & self.mask()
>>>>       }
>>>
>>> This is fine, too, although I think just returning an `Option` and ask user to
>>> unwrap it in const eval is better.
>>
>> Why? Aren't unwraps something we want to avoid?
>>
>> We already have fallible methods for non-const contexts, so why give
>> another method that essentially behaves the same when we want to use it
>> in scenarios where we know the result will be successful anyway?
>
> Unwrap is only bad when it can panic. It's not an issue for things that is
> apparently const eval only, e.g. inside `const {}` or `const FOO: Bar = baz`.

If we go that route we are just providing const versions of the
`align_up` methods of `Alignable`. Why not, but it looks very redundant
to me.