Change Clock trait to require interior mutable state?

[PTaylor-us]

I believe this this change must be made (now(&mut self) --> now(&self)) or every Timer function that needs to access the clock must be passed a &mut of the clock. I don't like the latter for the following reasons:

• Makes usage much more verbose
• Allows usage of different clocks with the same Timer

I think the last item is the greatest concern. What do you think @eldruin? How much more difficult would this make implementation? In my example implementation (using peripheral [not external]) timers, it doesn't change anything as the peripherals are all interior mutable already.

[eldruin]

I believe this this change must be made (now(&mut self) --> now(&self)) or every Timer function that needs to access the clock must be passed a &mut of the clock. I don't like the latter for the following reasons:

• Makes usage much more verbose
• Allows usage of different clocks with the same Timer

I understand. The same thing happens on drivers with the mutable I2C devices. The solution there is to consume the resource and return it upon destruction. See here. The return of the valuable resources can make code messy, though, if doing type-level transformations as highlighted at 2. here (sorry for citing myself again :) I just want to be clear).

Interior mutability would be ok for me. It can be worked around in the driver. It just requires the implementation to contain a RefCell to a second mutable layer. I used this to implement split() for the pcf857x I/O expander driver, among others. It is a bit cumbersome but it works. It only adds a CouldNotAcquireDevice error in case the acquisition failed, which cannot be statically reasoned about.