On Tue, 3 Feb 2026 13:28:15 -0300
Daniel Almeida <[email protected]> wrote:
> >> Now, this may not be the end of the world in this
> >> particular case, but for API consistency, I'd say we should probably avoid
> >> this
> >> behavior.
> >>
> >> I see that Alice suggested a closure approach. IMHO, we should use that
> >> instead.
> >
> > The closure, while being useful for the above local clk-enablement
> > example, doesn't allow for passing some Clk<Enabled> guard around, like
> > you would do with a lock Guard, and I believe that's a useful thing to
> > have.
>
>
> Wdym? You’d still get a &Clk<Enabled> that you can pass around, i.e.:
>
> self.prepared_clk.with_enabled(|clk: &Clk<Enabled> | {
> ... use registers, pass &Clk<Enabled> as needed
> });
>
> This is now not about clone() vs not clone(), but more about limiting the
> scope of the
> Enabled state, which would cater to the use-case you mentioned IIUC.
Fair enough. I guess it's more a matter of taste for that particular
case, and I'm not fundamentally opposed to adding this closure approach.
What the clone approach allows that's not doable with the closure
AFAICT, is something like:
let prep_clk = Clk::get(...)?.prepare()?;
let comp_a = MyComponentA {
prepared_clk: prep_clk.clone(),
}
let comp_b = MyComponentB {
enabled_clk: prep_clk.enable()?,
}
and have the guarantee that, as long as comp_a is alive the underlying
clk is at-least-Prepared, and as long as comp_b is alive the underlying
clk is Enabled.
