Named Returns

language design
1

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

1 Like
2

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)
7 Likes
3

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.

4

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.

1 Like
5

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).

2 Likes
6

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...

7

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 :wink:

7 Likes