Named Returns

[madman]

Natively. The caller gets an idea of what they're getting too. Please please, pretty please...

[cuviper]

Please provide details of what you're asking for -- don't assume that everyone has the same context as you. Language proposals also need a lot more than just a one line request.

I assume you're talking about this feature from Go:

• A Tour of Go: Named return values
  • Note the caution: "Naked return statements should be used only in short functions, as with the example shown here. They can harm readability in longer functions."
• In the specification: Return statements (variant 3)

[madman]

Yes, my bad, but the thing is, I don't myself know how it should be implemented either! Rust is a great language, a language that made all the right design decisions, and I'm afraid I'm not a great language designer. Do functions that only return a single value even need named-returns / even need to name the return value? I don't know; oftentimes, the function name gives a pretty good description of what the return value is, for instance, GetYCordinate(). So do only tuple returns need unambiguity? Should the names declare local variables in the declaring function or be purely aesthetic? I don't know. If tuples need naming, one should just use a struct. The thing is, structs can't be inline/anonymous. I reckon a decade ago, Rust did have anonymous structs (structural records, whatever). Maybe just bring back anonymous structs again... Should they be treated as tuples for all practical purposes, i.e., should type inferencing not take into account the names of the fields? I don't know... Lol.

[cuviper]

I suppose you could also have the "named return" function syntax without the "naked return" statements. I do recall proposals about anonymous structs before, especially for the idea of keyword args (like Python), but it seems reasonable that it could let you name return fields too.

[HeroicKatora]

There's some value in treating return-place(s) more similar to not-yet-initialized locals, in terms of language semantics. Including a much more concrete model for having multiple disjoint return values, clear obligations for the caller to uphold, some hints for syntax to make it more natural, etc. Of course there are also additional questions if we consider that places interact with lifetimes? There's also an overlap with in-place-construction here. Most certainly there is merit to the idea but also clearly some work in resolving it to a stable and well-defined proposal.

For turning the desire for the feature into a convincing RFC, I'd suggest choosing one of these ideas and building more concrete technical motivation around it, e.g. finding code that can not currently be written (soundly), patterns that become less cumbersome, or efficiency advantages. Then find and explain the / a potential mechanism by which named return values can address and overcome those current obstacles. (Also be prepared to show alternatives and their tradeoffs that make you choose named returns anyways).

[madman]

There already was, a very well-thought-out RFC for this, I've come to learn. The: https://github.com/rust-lang/rfcs/pull/2584 When it never made it through, I doubt mine ever would...

[steffahn]

I’ve noticed this was your second topic whose original post only contained a single sentence in the original post. As @kornel already pointed out in your first topic (admittedly, after you opened this topic, so perhaps this comment might be redundant), I would like to re-iterate in this topic, too, so you know for future topics, that a little bit more effort and details would be appreciated, not only for language proposals, but for forum topics in general.

At the very least, try to phrase your points in whole sentences, and don't rely on the title alone to relay most of what you have to say. And for language proposals in particular, of course, the more concrete, the better

[madman]

Yo, back to Rust! Been using @cuviper's apostrophe hack (Allow Apostrophe In Names - #3 by cuviper) in C++ the past few months; am pretty sure it'd work in Rust too. Named returns is now the only thing I wish Rust also had... https://crates.io/crates/named_return exists, but seems like an unnecessary overkill when something as basic as this can and should be supported by the language natively. The crate-author's original rfc (Language feature: named returns · Issue #2638 · rust-lang/rfcs · GitHub) mentions how named returns can potentially shorten function names too:

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>

Personally, I believe the whole point of OOP (which Rust does support the essense of) is dependency-inversion through interfaces; I believe it's impossible for humans to write code bottom-up, and instead much easier and effortless to design complex systems top-down instead. A level of indirection (the core of runtime polymorphic behavior) makes that possible. In the same spirit, "giving the programmer the ability to express themselves fully in code" should be the motto of Rust. If one doesn't detail what the return value(s) signify, months later, one could forget one's original intention when one's implementing those functions (trait functions, whatever). Much like how this little hack (or rather, neat little feature) enables the programmer to express in code their full intent of who/what they're expecting to be invoking the said function, and disabling other out-of-context uses of the function right at the compile time, while writing the declaration of the function outright! In English, if one were to document that, not only would it be many more words, but also one wouldn't actually be making any strides in actually developing the explained logic... One could document things in comments, but I believe that if writing detailed comments satisfies you, you're not gonna be making much progress in code; a good poetic programmer should document their visions in code (through high-level interfacing; traits; whatever), not in comments. An exception can be made for downright obvious one-liners, such as:

if (value < 0) {
   ...
}
else // value >= 0 {
   ...
}

Commenting return values would have totally satisfied me, but it seems the RLS-powered mouse-hover-tooltips trim down the in-line comments, destroying the whole point of the attempt.

Given

fn do_something() -> /*lucky_letter*/ char {
    return 'a';
}

the tooltip upon hovering over its usage only shows

fn do_something() -> char

Sad.