The Cancelable means that the operation can be canceled at any time, and Option is the usual "no reasonable value here".
Such signatures are a pain to work with, because ? does not work with nested options. It is especially visible when you convert an Option returning function into a Cancelable<Option> returning function: all those sweet ? have to be converted to the ctry! macro.
What are the practical approaches to deal with this problem in stable Rust (1.31.0 would also work)? Is the xtry! macro the best we can do?
Ideally, I'd love to have some .lift extension function on optionals which allows me to apply ?, but that seems impossible: ? can return only the Err value, and I need to return an Ok(None).
An additional property of my situation is that I inspect ("handle") None values pretty regularly, but I never inspect the Err(Canceled) value, I always propagate it upwards.
You could use the transpose function to swap the Option an Result, but thats currently on nightly, if you want this on stable you could create a small extension trait to do it.
In addition to the unstable method transpose() and the possibility to write this yourself, there are also the crates result and insideout providing this functionality.
Ah, I see. Well, the best I could come up with involves unstable try blocks and separating functions based on whether they return Cancelable<Option<T>> or plain Option<T>: Rust Playground
Would it maybe make sense to upgrade Cancelable<Option<T>> into a proper type with its own impl of the Try trait?
I remember a suggestion for labeled try operators (link), but I wouldn't hold my breath waiting for them.
I've come up with an even shorter version that combines try and transpose(), but it's unfortunately less scalable: Playground link. As you can see, it requires a type annotation and explicitly mapping over the Cancelable. But I thought it might still be interesting.