I think that mental model is a legit way to look at it. However, I consider it a leaky mental model given how async programming works in Rust. At the end of the day, the function returns a future and every user needs to learn about that fact because:
- manual future implementations will always exist and they return futures
- when using the initialization pattern the fact that a future is returned surfaces in the signature
- you always need to pass your future to an executor in order to start it
Hiding the underlying mechanism cannot and be done and doing it partly just muddies the waters.
I program a lot in JavaScript and it's the same thing with JavaScript promises: They represent eventual values, but they're objects in their own right because there's plenty of stuff that you can do with them directly. That's why I consider JavaScript async functions as simply normal functions that return promises. This way of thinking has worked well for me over the years.
(Edit: Removed incorrect response to @rpjohnst )
Exactly!
I think it should be this way around because the future would wrap the result. I don't see any compatibility issues with try fn no matter whether we use the outer return type or inner return type approach. Interestingly, the most recent proposal for try fn used an outer return type approach for try fn. (Off-topic side note: I'm currently unconvinced that try fns are a good idea)