Kind of with Rust had a notion of `impl TryDrop` for running destructors that can be unsuccessful. Could handle errors gracefully in Result contexts. Call `.unwrap()` in other contexts. Manually dropping through `try_drop(my_fn())?;`
-
Show this thread
-
Replying to @yoshuawuyts
Could you expand on how this would work? Destructors are called automatically -- there's no way to "try" them.
2 replies 0 retweets 0 likes -
Replying to @ManishEarth
My understanding is that when `drop(foo)` is called, the destructor is run. This can be done manually, or more commonly it happens automatically when the value goes out of scope. `try_drop(foo)?` would be the manual, fallible equivalent. But provides a Result escape hatch
1 reply 0 retweets 0 likes -
Replying to @yoshuawuyts
`drop(foo)` is literally `fn drop<T>(x: T) {}`. It's a no-op function, it works by letting the value fall out of scope.
2 replies 0 retweets 0 likes -
Replying to @ManishEarth
Right. But it's not a no-op for Mutexes, DB connections, files, etc. right? That's more the angle I'm thinking about. Would there be a way to handle errors in destructors there, but don't force API consumers to remember to copy boilerplate.
2 replies 0 retweets 0 likes -
Replying to @yoshuawuyts
> But it's not a no-op for Mutexes, DB connections, files, etc. right? No, i mean the drop() function isn't special. It's written as a no op, it works by letting the value fall out of scope. https://doc.rust-lang.org/beta/src/core/mem.rs.html#770 …
2 replies 0 retweets 1 like
Ahahaha, okay that's pretty cool. I thought there had to be more to it, but that's really clever!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.