Language feature: named returns

Optionally name the return types, as follows:

fn some_fn(a: A, b: B) -> (_a, _c): (A, C) {
    // ...
    let xxx: A = ... ;
    let yyy: C = ... ;
    (xxx, yyy)
} 

or perhaps, even:

fn some_fn(a: A, b: B) -> (_a: A, _c: C) {
    // ...
    let xxx: A = ... ;
    let yyy: C = ... ;
    (xxx, yyy)
} 

A few observations:

1. Increase in verbosity is always a struggle, but there is a chance for function signatures to convey meaningful information, if needed.
2. In this case the tuple return, the right-side (with cosmetic field naming) -> (_a: A, _c: C), actually looks visually similar to the left-side (a: A, b: B) -> . So I don't think this optional syntax addition looks THAT alien.
3. I expect that no function's body would need any change, whether adding or removing the return's naming information.
   1. Otherwise, perhaps _a and _c could be actually declared at the top of the function. But I personally dislike the Go's way, and I think that if _a and _c were indeed automatically declared and used in the function's body, the return would still need to be an explicit (_a, _c)-like expression.
      1. But if, for example, _a were to be mutable, then I guess the signature would have to be -> (mut _a: A, _c: C) instead ;x
      2. I'm not a macro spellcaster but I think this could be possible with macros and/or with attributes on functions.

This idea is based on ADA's in/in_out/out characteristics of parameters. From the little I read about it, each of their (function-like) procedures' outputs is just a normal (named) parameter tagged as out. If Rust were to incorporate that, I think the change would be the addition of names for the return type, since Rust already places the "out" parameters at the right-side of ->.

For example, the HashMap's insert could, instead of:

pub fn insert(&mut self, k: K, v: V) -> Option<V>

be:

pub fn insert(&mut self, k: K, v: V) -> _old_value: Option<V>

(I think the documentation keeps being necessary, as it is today, in this particular case)

I think some functions may have longer names in the absence of this cosmetic feature. Let's say..

pub fn insert_and_also_returns_the_old_value(&mut self, k: K, v: V) -> Option<V>

/exaggeration

Today, in most cases, the return type is implicitly "named" after the function's name itself. eg. the is_xxx() functions means that the return type (which is a boolean) could also be named "is_xxx".
But some functions' returns are not named after the function's name itself. For those cases, the return could be treated as a parameter which is "write-only" (as ADA's out parameters), and for being a parameter, could enjoy having a name for maintainability/documentation purposes.

Start with the issue's two proposed named-return syntaxes and the HashMap::insert example, then review the linked Ada reference for the intended semantics. Done requires a decided Rust syntax and semantics for return names, including whether they affect function bodies, rather than only documenting the proposal.