Add postfix return statements

[ghost]

There are a bunch of different ways to tunnel errors through asynchronous functions.

# You could use an if clause and indent your code.
# This is ugly, and inflates your indentation level.
processFile = (file, cb) ->
  fs.readFile file, 'utf8', (err, data) ->
    if err?
      cb err
    else
      cb undefined, doSomething(data)

# You could add a return statement to the end of your if clause.
# This can be hard to read, and still isn't a one-liner.
processFile = (file, cb) ->
  fs.readFile file, 'utf8', (err, data) ->
    if err?
      cb err
      return

    cb undefined, doSomething(data)

# Or, you could return the call to the callback.
# This, though, leaks the callback return value,
# and is kind of an abuse.
processFile = (file, cb) ->
  fs.readFile file, 'utf8', (err, data) ->
    return cb(err) if err?
    cb undefined, doSomething(data)

# You could use parentheses to combine the callback call
# and return statement.
# This requires the usage of semi-colons, and an extra set
# of parentheses.
processFile = (file, cb) ->
  fs.readFile file, 'utf8', (err, data) ->
    (cb err; return) if err?
    cb undefined, doSomething(data)

---

I propose adding a postfix return statement - that is, adding then return to the end of an expression would execute the expression and then return nothing.

So, this:

processFile = (file, cb) ->
  fs.readFile file, 'utf8', (err, data) ->
    cb err then return if err?
    cb undefined, doSomething(data)

Would compile to this:

(function() {
  var processFile;

  processFile = function(file, cb) {
    return fs.readFile(file, 'utf8', function(err, data) {
      if (err != null) {
        cb(err);
        return;
      }
      return cb(void 0, doSomething(data));
    });
  };

}).call(this);

This doesn't break any existing functionality, as <expression> and return is already a parse error.

A more complex example:

readFiles = (directory, cb) ->
  fs.readdir directory, (err, files) ->
    cb err then return if err?
    output = {}
    for file in files then do (file) ->
      fs.readFile path.join(directory, file), 'utf8', (err, data) ->
        cb err then return if err?
        output[file] = data
        files.pop()
        cb undefined, output if files.length is 0

---

In the attached implementation (which includes tests), and return, appended to a statement, is rewritten to a POST_RETURN token (the rewriter watches for a LOGIC/&& token followed by a RETURN/return token). This then triggers a special case on the Return node.

Thoughts?

[epidemian]

While the purpose is noble, i don't like the usage of and for this. and is a boolean operator with short circuiting and is quite often used to express conditional execution (mostly in JS; no so much in CS, as it has the post if form):

validateMove() and makeMove()

This proposal would make the right-hand side of the and (return) to always execute irregardless of the result of the left-hand side, which i think is counterintuitive.

Maybe another keyword could be used. This is also a compiler error as of now an also reads quite nicely:

cb err then return if err?

I personally don't see that much value in adding this... but we shall see.

[mehcode]

Agreed that I don't see value in this.

However I would prefer <expression> then return [<expression>] as well.

[ghost]

@epidemian You're right! then return would be a much clearer choice. Updated.

[michaelficarra]

I don't like overloading the then keyword. then introduces a block on a single line. I think it should stay that way.

[ghost]

What about dropping the "linking" keyword entirely, then, and having "return" as a simple postfix operator like if?

cb err return if err?

[davidchambers]

A higher-order function can provide much of the benefit of the proposed syntax addition:

handleError = (errorHandler) -> (success) -> (err, rest...) ->
  if err then errorHandler err else success rest...

With handleError:

$$ = handleError callback
Fodo.roots $$ (roots) ->
  root = _.find roots, predicate
  Fodo.children [root], $$ (children) ->
    # ...

Without:

Fodo.roots (err, roots) ->
  if err
    callback err
    return
  root = _.find roots, predicate
  Fodo.children [root], (err, children) ->
    if err
      callback err
      return
    # ...

[jashkenas]

Yep -- I don't think we should expand the meaning of then just for this. Indenting for these cases really ain't so bad:

if err?
  cb err
  return

In an unrelated thought -- is there any good reason why return isn't an expression (at least syntactically)? Other than that you can't actually use it as one? func(thing) && return seems like it would be useful in JavaScript.

[epidemian]

@jashkenas,

In an unrelated thought -- is there any good reason why return isn't an expression (at least syntactically)?

Is there any distinction between "statement expression" and "value expression"? I could see a statement like func(thing) and return something, where return would act as a statement, making sense and being useful; but something like val = return something or func(return 42), where return acts as a value, wouldn't make much sense.