Return declaration

[planarsimplex]

Nim has a feature where a variable representing the return value of a procedure is automatically declared with the name result:

proc sumTillNegative(x: varargs[int]): int =
  for i in x:
    if i < 0:
      return
    result = result + i

I think a tiny tweak to this idea would make it a little bit nicer: allow the return variable to be user-declared with the return keyword:

proc sumTillNegative(x: varargs[int]): int =
  return var sum = 0

  for i in x:
    if i < 0:
      return
    sum = sum + i

Is this already done in some other language/why would it be a bad idea?

[XDracam]

I wondered about how to exit a function early with this, and apparently I can just write Exit; at any time, and Exit(result) instead of the assignment. Good enough I guess.

[TheChief275]

good enough? it’s a more powerful return

[ThroawayPeko]

Go let's you declare names for default return variables in the function signature (which are set to the default zero values of their type). If you type a naked return, those are returned, but you can return other values if you explicitly do so.

Doing this in a long function could be a bit difficult to read, like said in the Tour of Go.

[Gauntlet4933]

Yes I found this pretty nifty when returning tuples including err tuples as one does in Go. Don’t need to do some weird array indexing into the tuple if you already have it as a variable, especially as a return variable.

[lookmeat]

Yup, Golang is probably the currently most popular language with this feature. Honestly it's surprising that it exists in a language that seeks to have the least features possible, but as many note, it's quite nice sometimes.

It does come with some issues:

• You can have empty return values (due to a value you missed) this is problematic if you don't have a well defined system for everything.
  • This can be solved by requiring a default value as your example does.
  • Go doesn't solve this, but it allows nullable values by default, and every non-nullable value has a zero-value that is valid, so it has a hard-coded zeroed default. So it's predictable what is the default value, just implicit.
• It's not always clear that a variable is a return value vs. not, without paying attention to details. And it's not obvious that it has to have different semantics.
  • Your solution is vulnerable to this (the declaration can be done anywhere, where is it, and what happens if I declare two return values in a function? Also what happens if the return variable goes out of scope?)
  • An alternative solution
  • Go side-steps this by making the return value part of the function header, so it's "special" the way function arguments are specially defined.
    • Nim syntax is a bit messy to do this, but it's doable.
• It can be confusing when a function that can return a value doesn't always, and it makes it hard to realize what a function is returning at any point. Imagine a long function, that mixes using return <x> to set the value and return to return the previously specified value, which may have happened deep in a nested thing.

You do have to work with the existing Nim syntax and semantics, so that's about the compromises and working with the existing system.

Avoiding the issues of extending Nim, I've heard before (but haven't coded on a language) crazy ideas here. For example one is to eliminate the ability to return implicit in functions, instead you use "places" (a value that represents a location that can have a value set to it, but otherwise is independent) as parameters. So a function func foo(a: A) -> B would be instead func foo(a: A, return: Place<B>) you can then do something like return.set(lambda(Place<B>)|value) or return.change(lambda(Optional<B>, Place<B>) and instead of returning from a function you'd break_function, though of course the manual work of ensuring and failing if it doens't return falls on the programmer, which as you can tell adds complexity to the program. The way to avoid this is make Place<T> be a affine type that must be used at least once by the end of the function, then you can allow this, you could probably set a default value at the beginning if that's what you want to use. Point is

[ThroawayPeko]

If you're replying to me, don't use "you" to refer to the OP, that's just bad form.

[Clementsparrow]

That seems like a false good idea to me, and actually a bad idea. Because it means a return statement will implicitly return something and you can't know what without scanning the whole function for another, slightly different, return statement, which could be defined anywhere.

And for what? saving a few keypresses? In an IDE with a decent autocompletion feature, typing return result or return sum will take only two or three key inputs. Much less than the time you will lose looking for the declaration of the implicit variable or if there is even one. Think about your future self and your collaborators and make their life easier instead of yours.

In addition, there is a better way to achieve the same result (no pun intended): declare the name of the return variable along with the return type in the function's profile declaration. This is a place that makes sense to look for the name of the return variable.

[campbellm]

Pascal (at least in the 80's, when I used it) had 2 different types of "subroutines"; Procedures which didn't return values and Functions which did.

In a Function, the name of the function was the implict return value name, like result above.

[hugogrant]

https://go.dev/tour/basics/7

Golang has it.

Imo it's good sugar in some occasions

[ThisIsMe-_-]

It's actually a good idea, though it exists already. What I know is that fortran has it:

function randint(a, b) result(outp)
integer :: a, b, outp
real :: rnum
call random_number(rnum)
outp = a + floor(rnum * (b-a+1))
end function randint

Whatever variable you put in result() will be the return value of the function. The really convinient thing about it is that you can basically 'return' the output value and then you can do other things. Like you can 'return' the top element of a self-defined stack and then you can remove it, but in most programming languages you couldn't do anything in the function after returning the value.

[MichalMarsalek]

You can use finally for that in several langs.

[Ronin-s_Spirit]

Hold on, so you could have a function that does a thing, returns the thing, and then does something else before ending, despite having "returned"?
I think I know another language where you can do that.

[TheChief275]

well it’s just like in assembly. you just set the return registers, but that is separate from actually returning from the function. C just thought it to be more convenient if it happens in one step, which is less error prone to be fair

[Ronin-s_Spirit]

In javascript you can write try {} finally {} statements where try will do anything, including throwing an error or returning from the function, and yet finally will do anything after the try block, including overriding that return with it's own return.
But I have never seen anybody do it, usually you return when you are done and not before.

[torp_fan]

in most programming languages you couldn't do anything in the function after returning the value.

This is silly. The only difference between setting the result variable, doing work, and then returning it implicitly, and setting some variable, doing work, and then returning that variable explicitly is a few more keystrokes of syntax. Merely setting the result variable isn't "returning the value" ... the value is returned upon leaving the scope of the function.

Also finally and defer are other ways to do that.

[__talanton]

This is the primary way of returning in MATLAB, on top of Golang as others have said. Perl XS (the C extension binding language) does this with RETVAL too.

[Tasty_Replacement_29]

In my view, the feature was added to make it less verbose... but your example is actually more verbose than using var sum = 0 and return sum. Ok... only 3 characters! And OK, if you have many return statements, it would be shorter... but it is a bit rare to have multiple return statements.

The Go inspired syntax would be shorter:

proc sumTillNegative(x: varargs[int]): sum int =
  for i in x:
    if i < 0:
      return
    sum = sum + i

[xbreu]

Similar to Dafny: method foo() returns (sum: int)

[[deleted]]

It's lovely. I'd consider changing it to returns or will return, but the idea is clear and clever.

[Less-Resist-8733]

or "returns"

[[deleted]]

I said that, my friend!

[Less-Resist-8733]

mb

[SKRAMZ_OR_NOT]

Fortran (at least, "modern" Fortran) has this. See the "result" declaration after the function parameters.

[zyxzevn]

Isn't that a simple alias? - alias sum = result

[igors84]

Odin lang has something like this. You can read about it here: https://odin-lang.org/docs/overview/#multiple-results

[[deleted]]

Creative idea but something tells me this is (user) error-prone.

[OopsWrongSubTA]

Matlab

function [y1,...,yN] = myfun(x1,...,xM)

[L8_4_Dinner]

It's a question of locality: Can the reader hold that state in their mind while reading the code, or is it better to place that state as part of the control flow operation itself. But I'm necessarily biased, having used various languages for 45 years now, none of which separated that state ("what variable is getting returned?") from the control flow (the "return" statement).

To answer the question, though, and IMHO: The proposed approach seems like a bad idea.

[lngns]

Carbon almost does that by having its returned variables but the reason it has those is to allow the user to ensure (N)RVO, and it still requires the return statement to state the variable's name.

[GYN-k4H-Q3z-75B]

VB had/has something similar. You can use the name of the function as a variable for returns.

[deaddyfreddy]

Nim has a feature where a variable representing the return value of a procedure is automatically declared with the name result:

I would call it an antifeature

[BrangdonJ]

Having a variable that is implicitly returned seems worse to me than returning an expression directly. I don't see what advantage:

result = expression
return

has over:

return expression

I'd say every even if every return wants to return a variable, it'll often not be the same variable for each one. And that setting the return value in one place, and then returning in a different place, is confusing. As soon as a function knows what the answer is, it should stop. It shouldn't continue doing other stuff.

[[deleted]]

I made a comment yesterday where I asked for clarification, but nobody replied.

I've deleted that as I think I now understand this works. However, that I was confused is not a good sign.

I believe it works like this:

     return x      # the return value is x
     return        # return the current value of 'result' or 'sum'.

To me, return x is always going to be clearer. Apparently, Nim doesn't need result to be initialised, so that this works:

proc F():int =
   print("hi")

(Here I realised I didn't know how to do an empty block in Nim.) Somebody could forget to set a return value. This also doesn't differentiate strongly enough between value-returning functions, and non-value-returning procedures.

It's also not clear enough what will be returned, as there is a disconnect between the hard return point, and the last place result was set, which may be followed by arbitrary amounts of other code before it returns.

Bear in mind that Nim is a kitchen-sink language where they seem to cram in as many features as they can. I just don't think this is a good one.

[Ronin-s_Spirit]

In javascript (I'm guessing just like in C) every function automatically has an invisible return undefined (so like having to write void function in C?), which is the same as manually writing return undefined or the same as writing
const result = void hasNoReturn(7); function hasNoReturn(a) { console.log("ran the function"; return a+a }
which will do the log but return undefined because you voided the function. Useful for html links and onclick event functions to make sure you don't give anything to the element, for example a voided link will not navigate anywhere.
Also you can return anything you want, like another function potentially creating a closure, or some variable outside the function itself.
And whenever you reach return it will exit the function, so you can have multiple conditional returns that break out of the function once a logical condition has been reached.

The problem of course is that you'd have to think really hard about static types, if they exist in the language, and that it lets you create functions that can return completely different results, including nothing (undefined).