V: ruby style return

[kostya]

hi, this language looks very interesting, i want try it. i see in many places many returns functions, i think would be nice to have return like in ruby, just last value:

fn cos(a f64) f64 {
    C.cos(a)
}

instead of

fn cos(a f64) f64 {
    return C.cos(a)
}

[medvednikov]

This is something I've been considering.

For more than 10 years I've only been using languages with explicit returns, but I can see how implicit returns would make sense in an immutable and partially functional language like V.

If it is allowed, it will be enforced by vfmt, so that there's only one way of returning a value in a final statement.

Very interested in what others think about this.

[medvednikov]

Besides, we already have this in if expressions:

foo := if true { bar } else { baz }

[dcurrie]

It would be nice to have no return in a final statement, or branch of a final statement like if or switch. This should be applied recursively, i.e., into nested switch and if statements of a final statement. This is the same flow analysis needed for tail call optimization. Then there would be little need for return at all, other than unwinding multiple control flow nesting levels in exceptional circumstances.

[metaprem]

I think it depends on the syntax of the language.

I like elm which does not have return.

but return also helps give visual clue as to where we are exiting out of function

Also much easier to find/grep.

so maybe it is not required but it helps with readability

[PavelVozenilek]

Smalltalk uses ^ instead of return keyword. It is visually not very prominent and awkward to type.

I personally would prefer to have some explicit indication of return, instead of implicit one. Function could get quite a big, and implicit return point would be way too easy to overlook. (This is not such a big deal in explicit if or C's ?:)

// What does it do, quick!
fn foo()
{
  if x {
    if y {
      foo
    } else {
      bar
    }
  } else {
    baz
  }
}

However, return has 6 characters to type, so perhaps
<-- x
or
=x /* = + no space + symbol means 'return symbol' */
would be shorter but still visually distinct.

[0x9ef]

Than you are not satisfied with the usual return expression? This is not an interpretable language such as ruby or python. It feels like you want to make a minimal, indistinguishable set of characters from a programming language ...

[SleepyRoy]

I prefer the traditional return statements. They act as "visual signals" and make it easier to understand the structure of functions.
Omitting is not always advisable. It's important to strike a balance between simplicity and explicitness.

[joe-conigliaro]

I think if its going to be implicit it had to be only at the end of a function, any other return must use explicit return statement (or some shortened verison) so as not to overlook early returns in functions.

[medvednikov]

I think if its going to be implicit it had to be only at the end of a function, any other return must use explicit return statement (or some shortened verison) so as not to overlook early returns in functions.

That's the plan, yes.

[joe-conigliaro]

I think if its going to be implicit it had to be only at the end of a function, any other return must use explicit return statement (or some shortened verison) so as not to overlook early returns in functions.

That's the plan, yes.

Excellent, I was just making sure as some of the previous comments were talking about something different. Personally I'm used to using languages with explicit return anyway and I think it's fine, some shortened return might be nice that can be used anywhere.

[dcurrie]

The V philosophy of "one way to do things" is nice. It violates this spirit if there's a way to return a value at the end of a function textually that's different from the way to return as value at the end of a function semantically. As someone experienced with expression-oriented languages (LISP, Haskell, ML, etc.), this inconsistency would be really obvious.

[medvednikov]

@dcurrie good point, I had the same concern.

If it is implemented, it will be the only way to return a value at the very end of the function. return would be used for returning a value mid-function, which is a different thing and is not even allowed in some languages.

So technically, there's still one way of doing things, but it does complicate the language.

The question is whether this complexity is worth it.

[boomlinde]

Explicit return seems better to me. With implicit return, the last expression of a function has a different meaning depending on function type (i.e. in a void function it doesn't mean return). Regular return syntax is anyway necessary to support early return.

Personally, I consider the times that I've simply forgotten to return the value that I wanted to return at the end of a function. Then it is more useful to me that the compilation fails than to have it assume that I wanted to return the last expression.

The disadvantages are only a mild concern to me, but so are the advantages (of saving seven characters in some cases), and I think the disadvantages outweigh the advantages, especially considering the note that this will complicate the language.

[medvednikov]

Thanks for your feedback. Explicit returns are going to stay, nothing will change.