On Sun Sep 20, 2026 at 10:50 PM JST, Gary Guo wrote:
> On Sun Sep 20, 2026 at 1:38 PM BST, Danilo Krummrich wrote:
>> On Sun Sep 20, 2026 at 2:20 PM CEST, Gary Guo wrote:
>>> On Fri Sep 18, 2026 at 7:03 PM BST, Alexandre Courbot wrote:
>>>> On Thu Sep 17, 2026 at 9:53 AM BST, Gary Guo wrote:
>>>>> On Tue Sep 15, 2026 at 8:39 AM BST, Alexandre Courbot wrote:
>>>>>> On Wed Sep 2, 2026 at 6:16 PM JST, Eliot Courtney wrote:
>>>>>>> Currently, using NonZero/Bounded constants is quite verbose. It's
>>>>>>> unfortunate because it disincentivizes using it in interface boundaries.
>>>>>>> Introduce a macro to make it nicer to use. The macro `cv!` (for constant
>>>>>>> value) takes a const integer expression and widens it to i128 (at build
>>>>>>> time only) before passing it as a const generic value to a new trait
>>>>>>> `FromConst`. The value is then converted and appears in the
>>>>>>> associated constant `FromConst::VALUE`. The trait is implemented by
>>>>>>> NonZero, Bounded, and Alignment and lets values of each be constructed
>>>>>>> from constants without a verbose turbofish syntax.
>>>>>>> For example, `const { NonZero::new(1).unwrap() }` can be written as
>>>>>>> `cv!(1)`.
>>>>>>>
>>>>>>> Suggested-by: Gary Guo <[email protected]>
>>>>>>> Signed-off-by: Eliot Courtney <[email protected]>
>>>>>>
>>>>>> I don't think we have any user but nova-core at the moment, and it
>>>>>> benefits from this in several series (patch 3 here, but also ID pool and
>>>>>> later r000). Miguel, is this ok if we take it (i.e. the next revision)
>>>>>> through drm-rust-next?
>>>>>
>>>>> How about a topic tag shared between Rust and drm-rust-next? We could also
>>>>> remove the old num casts API as part of topic tag and fix all existing
>>>>> users as
>>>>> part of merge.
>>>>
>>>> Not opposed to the idea but IIRC there was already some pushback to the
>>>> idea. There doesn't seem to be an urgency to remove the old num casts
>>>> API that justifies doing it now with a more complicated merge path.
>>>
>>> Sorry, what pushbacks? I thought that `cv!` is what everyone agrees on. I
>>> see no
>>> downside of this compared to the turbofish const conversion APIs.
>>>
>>> I am not opposed to delaying removal for the next cycle, but IMO the `cv!`
>>> macro
>>> should be present on Rust tree so it's visible and improvements can be made
>>> from
>>> there, so I think we should do a topic tag regardless whether the old API
>>> removal happens or not.
>>
>> I think Alex refers to this thread [1]; there's was some more context to this
>> though.
>
> Right, so "pushback" here relates to the logistics of old API removal, not the
> idea of `cv!`?
Correct - sorry about the confusion.
