Want to build a tool to document papercuts. I think there's a lot of value to be had in documenting the small speedbumps you experience, at the time you experience them. Think the optimization path from "good" to "excellent" often lies in figuring out where the papercuts are.
It's not because its always executed, which defeats the purpose. I cover both versions in the post - perhaps it wasn't being clear enough :/
-
-
`or_else` takes a closure which is only executed if the Result is an Err and which returns a new Result. i think it's actually the same as your `unwrap_or_result` idea https://doc.rust-lang.org/std/result/enum.Result.html#method.or_else …
-
Ahhhh, yes okay - that looks a lot closer! Looks like it only applies to Result types though, not Option types. So still don't think it would solve this case. But it's getting closer!
- 8 more replies
New conversation -
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.