Re: [PATCH v5 1/7] rust: time: make Delta generic over its time unit

On Mon, 10 Aug 2026 13:24:56 +0200
Andreas Hindborg <[email protected]> wrote:

> "Alexandre Courbot" <[email protected]> writes:
> 
>> On Fri Aug 7, 2026 at 9:10 PM JST, FUJITA Tomonori wrote:
>>>>> +
>>>>> +impl TimeUnit for Nsec {
>>>>> +    type Repr = i64;
>>>>> +}
>>>>> +
>>>>>  /// A span of time.
>>>>>  ///
>>>>> -/// This struct represents a span of time, with its value stored as nanoseconds.
>>>>> -/// The value can represent any valid i64 value, including negative, zero, and
>>>>> -/// positive numbers.
>>>>> +/// The span is stored in the unit given by the type parameter `U` (see
>>>>> +/// [`TimeUnit`]); its value has type `U::Repr`. `U` defaults to [`Nsec`], so a
>>>>> +/// plain [`Delta`] is a span in nanoseconds. The value can be negative, zero, or
>>>>> +/// positive.
>>>>>  #[derive(Copy, Clone, PartialEq, PartialOrd, Eq, Ord, Debug)]
>>>>> -pub struct Delta {
>>>>> -    nanos: i64,
>>>>> +pub struct Delta<U: TimeUnit = Nsec> {
>>>>> +    value: U::Repr,
>>>>>  }
>>>>>  
>>>>>  impl ops::Add for Delta {
>>>> 
>>>> When you add `Jiffy` later, this impl block will only cover
>>>> `Delta<Nsec>`. Is that intentional, or did you intend to support
>>>> all these operations operations for `Delta<Jiffy>` as well?
>>>
>>> Intentional. Delta<Jiffy> exists to carry a jiffies-valued timeout
>>> across the C boundary; it is not meant as a general arithmetic type. I
>>> can add them if a user needs them.
>>
>> Is there a reason for not doing it now? Common arithmetic sounds useful
>> for any unit, and since they are already agreed to panic at the bounds
>> we can constrain them on `U` implementing the corresponding traits.
> 
> I agree, I think we should add these. Unless there is some reason
> preventing us from doing so?

No reason for `Add`, `Sub`, `Mul` and the `*Assign` variants. `Div` is
the one exception:

https://lore.kernel.org/rust-for-linux/[email protected]/


> If you guys are in a super hurry to land this series, and if Miguel is
> still fine with taking this so late, you can add the arithmetic next
> cycle.

The reason for landing it this cycle is Gary's point from earlier in
the thread: the users can then be added in the next one. I expect
those users to come via a GPU tree, so it would save some coordination
later.

Miguel, would you still be happy to pick this up? I'll send the
arithmetic as a follow-up next cycle.