yosh

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!

Option has or_else which you can return another Option from, and `ok_or_else(fn)` which turns an Option<T> into a Result<T, E> in a similar way https://doc.rust-lang.org/std/option/enum.Option.html#method.ok_or_else …

Yeah, but I'm still not seeing any way where we can handle errors inside the None branch. How would the initial example be expressed with these statements? I feel like I'm missing something obvious?

let node = self.cache.get(key) // Option<K> .ok_or_else(|| self.db.get(key))?; // Result<K, E> can be ?-ed // node is now a K

Ahhh, yeah I see where you're going. But believe there's a mistake there. The type returned by the closure will end up being: Result<Result<K, E>, E> Which is incompatible with the return type from `self.cache.get()`. So we'd still need to do `self.db.get(key).unwrap()` :(

No, the closure's Result *is* the return value of x.ok_or_else if x is None, it doesn't get wrapped