Re: [PATCH v2 02/14] rust: hrtimer: introduce hrtimer support

[Benno Lossin <benno.lossin@proton.me>]

On 23.09.24 18:35, Andreas Hindborg wrote:
> "Benno Lossin" <benno.lossin@proton.me> writes:
>> On 19.09.24 07:43, Andreas Hindborg wrote:
>>>>> +    /// until the timer is unarmed and the callback has completed.
>>>>> +    ///
>>>>> +    /// Note: It must be safe to leak the handle.
>>>>> +    type TimerHandle: TimerHandle;
>>>>
>>>> Why does this need to be an associated type? Couldn't we have a
>>>> `TimerHandle<T>` struct? The schedule function below could then return
>>>> `TimerHandle<Self>`.
>>>
>>> At one point, I had some cycles in trait resolution. Moving generics to
>>> associated types solved that issue. Maybe this can be changed to a
>>> generic. But are generics preferred over associated types for some
>>> reason?
>>
>> The associated type is more complicated IMO, because then every
>> implementer of the trait needs to create one. If we can avoid that, I
>> would prefer a generic type.
> 
> When you say create, you mean specify?

Yes.

> Users would not invent their own type to put here, they would use the
> types defined by the `hrtimer` module in later patches.

I mean the implementers of this trait, not the users of the trait. You
define an `ArcTimerHandle`, `PinTimerHandle` and a `PinMutTimerHandle`
in this series. I think we can avoid that using a single generic struct.

---
Cheers,
Benno