David Barsky

@vorner I haven't had the time to work on this, I'm sorry—a lot of life happened. This is something that others can/should pick up, as I think the initial issue...

I'm in favor of this change, or something that looks a lot like this. This is something that I've run into often.

I'm onboard with a core-error, but I don't really have the bandwidth to provide feedback at the moment. Once it reaches 1.0—_personally_ speaking—I think it ought be integrated with Failure!

Yeah, I think moving this to `rust-lang-deprecated` is best.

That is my approval to move this repository in the near future, or whenever you are ready to do so. Sorry that my response was unclear but thanks for double-checking.

I'll reproduce @yoshuawuyts' comment here: > @davidbarsky If error handling is expressed as a graph, I currently use Failure's Fail trait to define "leaf node" errors, and Failure's Error struct...

> Coincidentally, have you considered writing about Failure's 0.2 design? Back in 2017 Boats wrote a post introducing failure. I think it'd be cool if there'd be something similar for...

> I want to dive into the motivation a bit more. Sure! I think if I'm to summarize my motivation, it'd be the following: - At higher read/writes rates on...

Thanks for commenting on this! Can`BUGGIFY` be seen as a general purpose failpoint-like system (e.g., https://github.com/tikv/fail-rs)?

I was considering sketching out something closer to the Simnet approach for this, where we’d [generate actions that’d be executed by the simulator](https://rust-fuzz.github.io/book/cargo-fuzz/structure-aware-fuzzing.html#example-2-fuzzing-allocator-api-calls). The actions could be API calls or...