While experimenting with scope rules in Rust, I ended up implementing a recurrent idea I had – a RAII guard that runs a function when the object goes out of scope. I’m well aware of scopeguard crate, but it has some stinky unsafe bits in its implementation.
I was never able to properly implement it, probably because my Rust skills weren’t good enough, but now I did. And I’m rather satisfied with it:
use std::ops::Deref; /// Returns the object wrapped in a way that the associated closure will run /// when it goes out of scope. pub struct Guard<T, D: FnOnce(&mut T)> { asset: T, dropper: Option<D>, } impl<T, D: FnOnce(&mut T)> Drop for Guard<T, D> { fn drop(&mut self) { self.dropper.take() .map(|d| d(&mut self.asset)); } } impl<T, D: FnOnce(&mut T)> Deref for Guard<T, D> { type Target = T; fn deref(&self) -> &Self::Target { &self.asset } } impl<T, D: FnOnce(&mut T)> Guard<T, D> { /// Creates a new `Guard` object. pub fn new(asset: T, dropper: D) -> Guard<T, D> { Self { asset, dropper: Some(dropper) } } }
I though about writing stuff like this in WinSafe:
impl HWND { pub fn GetDC(self) -> WinResult<Guard<HDC, impl FnOnce(&mut HDC)>> { Ok(Guard::new( self.GetDC()?, move |hdc| { self.ReleaseDC(*hdc).expect("Guard crash."); }, )) } }
But then there are big implications like CreateMenu
, which may or may not require a DestroyMenu
call. These dubious behaviors are very unsettling, and many questions arise:
- Should I write another method, with a
_guarded
suffix? - Mark the unguarded original as
unsafe
? - In the example above,
self
is copied into the closure – what if it’s still zero?
So by now I believe I’ll leave everything as it is, and let the defer-lite crate at hand when needed.
Still, I greatly miss the idiomatic defer
in Go.
No comments:
Post a Comment