Returning to this, I think this might be the best fit. I have generally opposed
fn try_fn() -> T throw[s] E
in part due to concern about obscuring the external return type and in part because calling a function cannot “throw” on its own; only a ? expression can. However, with the async proposal using the interior return type of the function in the function signature, and the possibility for yield, i.e.
async fn foo(arg: Arg) -> Return yield Yield
it seems like it’s better for the language to do this consistently for this type of feature. In each case, Rust is exposing a value reifying the annotated effect at the function boundary, but leaves this type unmentioned in the function signature. And in each case (well, I’m not sure about generators, but certainly for futures and results), there’s an associated caller-side syntax which explicitly propagates the effect. If the annotation marking this effect in a function signature is throw[s], then logically, propagating that effect is ‘rethrowing’.
Of course, a consistency argument only gets you so far. Certainly the trade-offs are different in each case, with the arguments for how async handles the internal/external return type dichotomy being particular to that case. I don’t think the pedagogic value of being able to say that the noted return type is always the internal return type can be dismissed, however.
