3 ms·
I was contemplating what it would look like to provide this with a macro in Rust, and of course someone has already done it. It's syntactic sugar for the destru
by dwattttt 10mo ago
I was contemplating what it would look like to provide this with a macro in Rust, and of course someone has already done it. It's syntactic sugar for the destructor/RAII approach.
https://docs.rs/defer-rs/latest/defer_rs/ https://docs.rs/defer-rs/latest/defer_rs/
- deleted 10mo ago[deleted]
- mojuba 10mo agoI don't know Rust but, can this `defer` evaluate after the `return` statement is evaluated like in Swift? Because in Swift you can do this: func atomic_get_and_inc() -> Int { sem.wait() defer { value += 1 sem.signal() } return value }
- ninkendo 10mo agoEDIT: I don’t think you can actually put a return in a defer, I may have misremembered, it’s been several years. Disregard this comment chain. It gets even better in swift, because you can put the return statement in the defer, creating a sort of named return value: func getInt() -> Int { let i: Int // declared but not // defined yet! defer { return i } // all code paths must define i // exactly once, or it’s a compiler // error if foo() { i = 0 } else { i = 1 } doOtherStuff() }
- mojuba 10mo agoHuh, I didn't know about `return` in `defer`, but is it really useful?
- deleted 10mo ago[deleted]
- ninkendo 10mo agoNo, I actually misremembered… you can’t return in a defer. The magical thing I was misremembering is that you can reference a not-yet-defined value in a defer, so long as all code paths define it once: fn callFoo() -> FooResult { let fooParam: Int // declared, not defined yet defer { // fooParam must get defined by the end of the function foo(fooParam) otherStuffAfterFoo() // … } // all code paths must assign fooParam if cond { fooParam = 0 } else { fooParam = 1 return // early return! } doOtherStuff() } Blame it on it being years since I’ve coded in swift, my memory is fuzzy.
- deleted 10mo ago[deleted]
- kibwen 10mo agoThis control flow is wacky. Please never do this.
- kibwen 10mo agoIt's easy to demonstrate that destructors run after evaluating `return` in Rust: struct PrintOnDrop; impl Drop for PrintOnDrop { fn drop(&mut self) { println!("dropped"); } } fn main() { let p = PrintOnDrop; return println!("returning"); } But the idea of altering the return value of a function from within a `defer` block after a `return` is evaluated is zany. Please never do that, in any language.