Re: [PATCH v2 0/3] rust: const_eval: add a mechanism to do const trait calls

[Gary Guo]

On Mon Sep 7, 2026 at 10:21 AM BST, Eliot Courtney wrote:
> On Fri Sep 4, 2026 at 12:46 AM JST, Gary Guo wrote:
>> On Thu Sep 3, 2026 at 4:34 PM BST, Miguel Ojeda wrote:
>>> On Thu, Sep 3, 2026 at 5:21 PM Gary Guo <gary@xxxxxxxxxxx> wrote:
>>>>
>>>> Add a mechanism to perform const trait method calls, with the same type
>>>> inference capabilities. This would only work for concrete types (not inside
>>>> generic functions).
>>>>
>>>> As an example, convert `as_char_ptr_in_const_context`, so instead of
>>>>
>>>>     kernel::str::as_char_ptr_in_const_context(c_str)
>>>>
>>>> one may write
>>>>
>>>>     const_call!(c_str.as_char_ptr())
>>>>
>>>> instead.
>>>>
>>>> Signed-off-by: Gary Guo <gary@xxxxxxxxxxx>
>>>
>>> Thanks for resending this!
>>>
>>> So I definitely like having `#[const_eval_only]`, because we do want
>>> to limit those calls sometimes and it is nice to have C++'s equivalent
>>> to `consteval` (perhaps this could be called just `#[consteval]` to
>>> match?); i.e. what we talked about in the call.

I'm okay with either. I put in `_only` because I think it makes it very clear
that this is not just const-evalutable (that's provided by `const`) and is
*always* const evaled.

>>>
>>> On `Const` and `const_call!`, i.e. the other two patches: I am not
>>> sure if we care that much to introduce a macro for it, but it doesn't
>>> look bad either. I guess perhaps it helps to have a consistent way to
>>> do it and to easily remove it later when the actual feature lands in
>>> Rust. I would like to hear some thoughts on it from others.

>>
>> I think it's good to have such macro compared to our current approach; it can be
>> made into a identity macro once we have const trait impl.
>>
>> FWIW, I even considered an extra macro that allow you to write
>>
>>     #[const_trait_impl] // #[const_trait_impl(foreign)] for core types
>>     impl MyTrait for MyType {}
>>
>> and generate the `impl Const` part too (and also add a line to the documentation
>> that the method is const-callable with `const_call!()`).
>>
>> Best,
>> Gary
>
> I agree with the consteval macro, that sounds very nice.
>
> On the const_call! I have similar thoughts to Miguel. I reckon if we
> have a bunch of prospective users of this right now, and some thoughts
> on what would use this in the future then it's good. If it's just one
> use case right now, then not so sure.

Some other candidates include `Alignable` (we currently have a "const_align_up")
and maybe `IntoSafeCast`.

Best,
Gary