| ▲ | dwattttt 3 hours 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/ |
|
| ▲ | 2 hours ago | parent | next [-] |
| [deleted] |
|
| ▲ | mojuba 2 hours ago | parent | prev [-] |
| I 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
}
|
| |
| ▲ | kibwen an hour ago | parent | next [-] | | It'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. | |
| ▲ | ninkendo an hour ago | parent | prev [-] | | 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()
}
| | |
|
