quoted

Yes, that would be great. I do wonder though if it wouldn't make sense
to turn it the other way around. It creates a fair share of boilerplate
for a number of drivers. Can't we keep Clk the way it is as a
lower-level type, and crate a ManagedClk (or whatever name you prefer)
that drivers can use, and would be returned by higher-level helpers, if
they so choose?

That way, we do have the typestate API for whoever wants to, without
creating too much boilerplate for everybody else.

One solution is to have a new typestate `Dynamic` which opts to track things
using variables.

struct Dynamic {
   enabled: bool,
   prepared: bool,
}

trait ClkState {
   // Change to methods
   fn disable_on_drop(&self) -> bool;
}

struct Clk<State> {
   ...
   // Keep an instance, which is zero-sized for everything except `Dynamic`
   state: State,
}

this way we can have runtime-checked state conversions.

Best,
Gary

There used to be a Dynamic state in the past in a similar setting. That was removed after some thorough discussion. I’d say we should refrain from going back to this. Specially considering that the current design works fine.

 I can remove the turbofish if you want, even though I think they’re useful so that we have the same API for all states.

— Daniel