delay: make infallible.

[Dirbaio]

1.0 alphas have been out for a while, some HALs out there implement it. I haven't seen one with an actual fallible delay.

I know the decision was made to make Delay fallible for consistency, but I think we should make one exception for just this one trait.

[eldruin]

I actually also have a hard time thinking about a failure mode for delay.
Maybe it could be useful in some HAL to end the delay early because something happened in an interrupt? (Same thing for the async version, without the need for an actual interrupt)

[Dirbaio]

I don't think we should allow that. The HAL should restart the delaying for whatever time's left, then return when the delay actually requested has elapsed.

It'd be very annoying for drivers otherwise, they would all need to write their own "retry loop".

[dbrgn]

It'd be very annoying for drivers otherwise, they would all need to write their own "retry loop".

I agree with this. When doing retry loops, you don't even know how much remaining time you have to wait without a timer. And if you're already using a timer, you probably wouldn't need the delay...

[Dirbaio]

This was brought up in today's WG meeting. No much discussion was had, some people expressed support and no one raised objections.

I think it should be good to go. Shall we merge? @rust-embedded/hal

[eldruin]

I'm fine with this.
Since breaks the current fallibility "policy", let's ask everyone.
@ryankurte, @therealprof: could you please review this as well?

[ithinuel]

Out of curiosity, is there a usecase for external clock source that could be fallible ? (eg delay with a timer over SPI/I2C)

[therealprof]

Fine with me.

bors r+

[bors]

Build succeeded:

• clippy
• fmt
• test (1.59.0, thumbv6m-none-eabi)
• test (1.59.0, thumbv7m-none-eabi)
• test (1.59.0, x86_64-unknown-linux-gnu)
• test (nightly, thumbv6m-none-eabi)
• test (nightly, thumbv7m-none-eabi)
• test (nightly, x86_64-unknown-linux-gnu)
• test (stable, thumbv6m-none-eabi)
• test (stable, thumbv7m-none-eabi)
• test (stable, x86_64-unknown-linux-gnu)