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

Already on GitHub? Sign in to your account

bypassing "always return something" #1401

bluescreen303 opened this Issue May 29, 2011 · 16 comments


None yet

I would like to use coffeescript for writing tests with the Vows framework.
Vows is able to do both synchronous and asynchronous tests.
For this to work, they chose to handle functions that return something as synchronous, and the ones that don't as async.
From their own documentation:

Note that topics which make use of ‘this.callback’ must not return anything. And likewise, topics which do not return anything must make use of ‘this.callback’.

So if I would like to be able to return nothing in certain situations.
I like the return-something-by-default approach coffee-script takes, so I'm not asking to change that.
However a noreturn statement of some kind will be helpful for this (and probably other) special case.

tchak commented May 29, 2011

maybe I am wrong, but I am pretty sure return undefined is equivalent to return nothing...

ah :)
why didn't I think of that before.

Indeed, it works, thanks

On Sun, May 29, 2011 at 10:42 AM, tchak

maybe I am wrong, but I am pretty sure return undefined is equivalent to return nothing...

Reply to this email directly or view it on GitHub:
jashkenas#1401 (comment)


michaelficarra commented May 29, 2011

Simply appending a return statement to the function body will return an undefined value, behaving just like a function that doesn't have a return statement.


TrevorBurnham commented Jun 7, 2011

By the way, I think Vows is a great example of where a syntax I proposed,


to define a function that doesn't return anything, would be very useful. Having to add return to the end of each test function is a pain, and greatly reduces the benefits of using CoffeeScript instead of JS. Having to use a * before the dash rocket still takes conscious effort, but at least it doesn't increase line count.


michaelficarra commented Jun 7, 2011

dash rocket

Oh, please don't start that. It's an arrow, right? Just call it an arrow. And => is a fat arrow.


TrevorBurnham commented Aug 13, 2011

For future reference: The issue on the "function with no return value" syntax was #899. My syntax of choice would be


visually suggesting that the function's output is "cut off."

👍 to the above proposition.

+1 here as well

+1 PLEASE. I hate all the returns i have to place everywhere.

Zearin commented Sep 7, 2012

+1! :D

again i vote for -/>

delaaxe commented Oct 19, 2012

How about using a semicolon to return nothing?

The following :

f = ->
  bar(); # notice the semicolon

could compile to :

f = function() {
  bar(); // no return here

While keeping

f = ->

compiling to (as always)

f = function() {
  return bar();

Inspired by http://lucumr.pocoo.org/2012/10/18/such-a-little-thing/


vendethiel commented Oct 19, 2012

I don't see how that'd be possible, it's actually working CS. ; already has its meaning.


epidemian commented Oct 19, 2012

@delaaxe, i don't think that's a good idea. I also really like what Rust made with semicolons... in fact, i also like what Python or Ruby do, they all are quite consistent in their own.

Now, what Rust does makes sense because semicolons are not statement terminators (as in C); they are expression separators. The empty expression is an expression and evaluates to nil (()), so if you have foo(bar); the semicolon is separating the foo(bar) expression from the empty expression, and as the last expression in a block is always returned, then nil is returned in that case.

So, in Rust, i think it not right to say "if you want to avoid returning the last expression, put a semicolon at the end" (as i would imagine newbie rusters will be told =P). The last semicolon does nothing magical, so i think i'd be better to say "just put an empty expression at the end".

Back to CoffeeScript. In CS semicolons are optional statement terminators (normally the newline is preferred), so, given that today

foo = ->

is equivalent to

foo = ->

I think it's not a good idea to give a new meaning to that optional last semicolon.

My vote is also for some sort of new arrow, like -/> or !->, or having a shorter syntax for return, like <-:

# Return something early:
foo = ->
  <- bar if baz

# Omit return:
foo = ->

I'f you s/<-/return/ that, it's just as today's CS semantics.

delaaxe commented Oct 19, 2012

@epidemian Really interesting, I will look further into Rust.

I find the special arrows ugly, but your suggestion of using <- for return is elegant though (imo).

jashkenas#1401 (comment)

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