Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a "returns" keyword so that code avoiding implicit returns makes more sense. #3081

Closed
monokrome opened this issue Jul 22, 2013 · 7 comments

Comments

@monokrome
Copy link

There should be a "returns" keyword - or at least some similar concept - so that code avoiding implicit returns makes more sense. Implicit returns still cause a lot of confusions to users of CoffeeScript. This allows us to designate which variable will be returned preemptive to reading the code (which helps readability in many cases) as well as is backwards compatible with implicit returns since this statement is explicit.

One example:

fn = (arg) -> returns result

  result = []

  for i in [1..10]
    result.push(i)

Another example, which beats the return null at the end alternative:

fn = (argA, argB) -> returns null
  arg.push argB
@michaelficarra
Copy link
Collaborator

You can accomplish the same thing with this helper:

returns = (v, fn) -> -> fn.apply this, arguments; v

Declaring the return value at some arbitrary point in the program and then continuing execution would be a good way to write terribly unreadable code. -Infinity, but not closing just yet.

@vendethiel
Copy link
Collaborator

Declaring the return value at some arbitrary point in the program and then continuing execution would be a good way to write terribly unreadable code. -Infinity.

Agreed.

@monokrome
Copy link
Author

Well, implicit returns already solved the problem of finding a good way to write terribly unreadable code. Using a wrapper function is not a good solution, because more calls means less performance to get around an issue that Coffee has unreasonably created.

The 'returns' statement should probably not be able to occur after the first statement in a function, also. That could make it unreadable.

@davidchambers
Copy link
Contributor

fn = (argA, argB) -> returns null
  arg.push argB

If explicitness is your goal, the following is arguably more explicit and doesn't require a new keyword:

fn = (argA, argB) ->
  argA.push argB
  return null

-1

@monokrome
Copy link
Author

The goal isn't only to be explicit. It's to be explicit without needing to return null at the end of the function. Providing returns null should conclude as:

var fn = function (argA, argB) { argA.push(argB); };

This might not be the best way to solve the problem, but there are plenty of issues which make this problem known - some of which have been entertained for quite a while - yet, there is still no solution in Coffee. Implicit returns are a problem, and something has to be done to ease the problem which they've created.

@epidemian
Copy link
Contributor

Providing returns null should conclude as:

var fn = function (argA, argB) { argA.push(argB); };

If you want a function to return undefined you can simply return:

fn = (argA, argB) ->
  argA.push argB
  return

The CoffeeScript compiler is nice enough to omit the redundant return from the compiled JS.

So yeah, 👎 for this proposed syntax expansion. Adding a different function token for functions that always return undefined (a.k.a procedures) might be worthwhile (though i don't mind at all if they are not included... less syntax is also a nice feature), but that has been discussed before.

@monokrome
Copy link
Author

There have been recommendations for doing things like ->> and =>> which is worse, in my opinion. All of the function combinations that coffee will have is just a bother and not helping readability in any way.

->
=>
->>
=>>

All of these different ways of writing a function? That is silly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants