The obvious name for the DelayNs trait is Delay, but we've reserved that name for a future, post-1.0 trait once we have a good Duration. Right now it's not clear what that Duration will look like or do, so we've been leaving thinking about it until later.
I suggest we rename the current DelayNs trait to Delay now anyway:
- Perhaps
DelayNs already does everything we want: pick a number of ns/us/ms to delay for, up to u32 of them, and you can always do it multiple times if that's not enough range
- If we don't ever find a
Duration type, it would be nicer to be stuck with Delay than DelayNs;
- if we do find the type, we could add a new method
delay(Duration) to Delay and provide a default implementation in terms of delay_ns(); if we keep DelayNs then once we find Duration we'll end up with both the new, good Delay and the old-but-kept-forever DelayNs
My main point is that perhaps what we have in DelayNs is already good enough to warrant using the name Delay, and it's nice that we could conceivably add a delay(Duration) method later (with some caveats) if we wanted to, while if we stick with DelayNs now, we're sure to always have DelayNs and maybe also have Delay, with all the confusion that multiple overlappnig traits has brought us in the past.
There are some downsides to "just add delay(Duration) later", though:
- We'd have to provide a default impl for backwards compatibility, presumably in terms of
delay_ns, whereas the obvious de-novo construction would be to default delay_ms/us/ns in terms of delay(Duration). This is a pain, but I don't think it constrains what Duration looks like (presumably we'll need to be able to convert it to ns somehow anyway), and we can document that implementors should prefer to implement delay() themselves, and then implement delay_ns in terms of delay.
- We'd lose the ability to have an associated type with
Delay, which could be used to require a certain timebase for example. I don't fully understand the negative consequences here, but maybe @Dirbaio can expand on them later.
- We might want the new
Delay trait to only ever have delay(Duration), without delay_ms() methods, as is done in the stdlib. We couldn't do this rename and then later delete those methods, so we would be stuck with them in Delay.
- something else?
It's not a slam-dunk either way, but it seemed worth discussing before we hit 1.0.
The obvious name for the
DelayNstrait isDelay, but we've reserved that name for a future, post-1.0 trait once we have a goodDuration. Right now it's not clear what thatDurationwill look like or do, so we've been leaving thinking about it until later.I suggest we rename the current
DelayNstrait toDelaynow anyway:DelayNsalready does everything we want: pick a number of ns/us/ms to delay for, up to u32 of them, and you can always do it multiple times if that's not enough rangeDurationtype, it would be nicer to be stuck withDelaythanDelayNs;delay(Duration)toDelayand provide a default implementation in terms ofdelay_ns(); if we keepDelayNsthen once we findDurationwe'll end up with both the new, goodDelayand the old-but-kept-foreverDelayNsMy main point is that perhaps what we have in
DelayNsis already good enough to warrant using the nameDelay, and it's nice that we could conceivably add adelay(Duration)method later (with some caveats) if we wanted to, while if we stick withDelayNsnow, we're sure to always haveDelayNsand maybe also haveDelay, with all the confusion that multiple overlappnig traits has brought us in the past.There are some downsides to "just add
delay(Duration)later", though:delay_ns, whereas the obvious de-novo construction would be to defaultdelay_ms/us/nsin terms ofdelay(Duration). This is a pain, but I don't think it constrains whatDurationlooks like (presumably we'll need to be able to convert it to ns somehow anyway), and we can document that implementors should prefer to implementdelay()themselves, and then implementdelay_nsin terms ofdelay.Delay, which could be used to require a certain timebase for example. I don't fully understand the negative consequences here, but maybe @Dirbaio can expand on them later.Delaytrait to only ever havedelay(Duration), withoutdelay_ms()methods, as is done in the stdlib. We couldn't do this rename and then later delete those methods, so we would be stuck with them inDelay.It's not a slam-dunk either way, but it seemed worth discussing before we hit 1.0.