Add a function syntax which does not return the value of last expression

[curvedmark]

Can we have something like this:

-|> @print('no return')
=|> @print('no return')

Which will compile into:

var _this = this;

(function() {
    this.print('no return');
});

(function() {
    _this.print('no return');
});

Having to put a standalone null or undefined at the bottom of a function if it doesn't need to return anything doesn't look quite good.
I choose "-|>" and "=|>" because the pipe looks like being "blocking" the function from returning, but the actual tokens are not important. They can be anything you like.

[michaelficarra]

duplicate of #1836, #1812, #899

[michaelficarra]

Just wondering, why do you care about return values that are unused? Performance of implicit comprehensions? And what's so hard about appending a return in the natural position for a return value rather than specifying it at the top with yet another syntax? I just don't get why this proposal keeps coming up.

[curvedmark]

I should have searched first, sorry about that.

I guess my reasons are mostly of esthetic kind (and I use coffeescript because of its beautiful syntax):

1. Having to append an explicit return is somewhat like having to append a break at a switch case. You want to get rid of it but you can't. So you just hate it. :)
2. It's not like we are adding a totally new syntax. It's more like adding expression if condition when we have if else, which feels very natural.

[michaelficarra]

But that doesn't answer my first question. What's wrong with the implicit return? Why must you return undefined when execution reaches the end of the function body?

[curvedmark]

Because sometimes I need to send the compiled js file to someone who doesn't know coffeescript. For example, if it were unit testing code, which has many assertions in each test. Each last assertion will be appended with return if I didn't write return explicitly, which doesn't look quite good.

A jasmine example:

describe "the code", ->
    it "should be correct", ->
        expect(1+1).toBe 2
        expect(1+2).toBe 3
    it "should be clean", ->
        expect(1+1).toBe 2
        expect(1+2).toBe 3

which gets compiled to

describe("the code", function() {
  it("should be correct", function() {
    expect(1 + 1).toBe(2);
    return expect(1 + 2).toBe(3);
  });
  return it("should be clean", function() {
    expect(1 + 1).toBe(2);
    return expect(1 + 2).toBe(3);
  });
});

[michaelficarra]

Ah, okay. Thanks.

[jcollum]

I feel like it's kind of a rough spot in the syntax. The syntax is 'just pay attention to indents to see where functions are ending'. Except when you don't want to return anything, you have to put this 'return' at the end. But many functions don't do anything, especially in the web world where most functions are click handlers that aren't returning anything. So it's non intuitive to me, could be because I'm coming from c#.

I'm just saying the majority of functions that I write don't return anything so adding in the return is awkward. The alternative is to return something (often a function like $('#theDiv').click etc) that doesn't have any meaning to the function calling it.

Really it looks like a style thing to me. I see the argument for both sides but the C# in my history makes me want returns to be explicit.