@est31 Thanks for substantiating the feeling I’ve had that something’s fishy with the "just coerce to Ok" approach, but couldn’t articulate 
I think the idea to use ? instead of throws in the signature would make sense if we left off the "Try type" in the same way as the throws proposal does. Because in that case, given fn blah()? -> i32 { 42 }, the intuition would be that the type of blah()? as an expression is precisely i32, which is kinda neat. But it unfortunately doesn’t seem like it can work, because it doesn’t leave anywhere to specify what the error type is.
Other things:
-
Someone suggested that a drawback of
throwsis that it would only work withResultand not otherTrytypes, but I don’t think this has to be the case. In principle, the body of athrowsfunction would never mention the variants of theTrytype it’s returning, they would only be created through?for errors and wrapping for ‘successes’. So in theory it could return anyTrytype we choose; but even if it returnsResultspecifically,Tryitself allows it to be converted to a different one. If I’m not missing something, thenfn foo() -> X throws Ycould desugar into any offn foo() -> Result<X, Y>,fn foo() -> impl Try<Ok=X, Err=Y>(in which case the only thing the caller could do with it is?or.try()), orfn foo<Res: Try<Ok=X, Err=Y>() -> Res(in which casefoo()would desugar to useTry::from_ok()andTry::from_err()at its exit points to convert to whichever type the caller requests), and they all seem like workable approaches (though I haven’t worked it out in detail). I’m not sure which one might be best. -
This is of course related to how
catchshould work. I’m of the opinion thatcatchshould just alwaysOk-wrap (orSome-wrap, etc.) its result, as in the original RFC, but I haven’t had time to read the GitHub thread about this. -
This also seems related to the design work around async/await, where
#[async]would implicitly wrap a function’s written return type in aFuturein a similar way to howthrowswould wrap it in aResultorTry.