Alternative return this

[Qard]

My code has lots of dangling @ symbols to make stuff chainable, I've been wondering if there is perhaps a more elegant way to represent that.

How about rather than this;

->
  # do stuff
  @

we do something like this;

@-> # do stuff

That way you can see right at the start of the definition that it is chainable.

[aslilac]

I don't see anything wrong with have an @ at the end.

This idea has good intentions, just I have a hard time thinking that it will actually get in.

[Qard]

Just a simple convenience thing. @arguments got in, which is a similar kind of convenience, so I think this could have a chance. Not really a big deal though. It'd just be a little easier to follow when you have a ton of chainable stuff.

[aslilac]

That's a good point.

The biggest reason I think this won't make it is the other "special syntax to make functions always return x" issues I've seen get brutally thrown down.

I guess we'll find out soon.

[michaelficarra]

@tylermwashburn: I'd be happy to be the first to fulfill that prophecy. Huge -1 from me for obvious reasons.

[erisdev]

Yeah, 👎 really. The only special function syntax I really favour is the one using void for returns-nothing functions.

[michaelficarra]

returning = (x, fn) -> -> (fn.apply this, arguments); x
yourFunction = returning @, -> # do stuff
anotherFunction = returning undefined, -> #899

[aslilac]

+1 @michaelficarra

I would change the function name to returns, but we.

[Qard]

@michaelficarra That doesn't work to well in object definitions. This edited version works okay, if you only need to support return this;

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

obj =
  foo: 'foo'
  bar: r -> console.log @foo
  baz: r -> console.log @foo

obj.bar().baz()

It's also not especially convenient if your code is split across a whole bunch of files. You have to add the r definition to the top of every file. Not very DRY. >.>

[STRd6]

If you want the sweetest syntactic sugar don't be afraid to extend Function.prototype

Function::returning = (x) ->
  func = this

  ->
    func.apply(this, arguments)
    return x

Similar to Michael's example:

yourFunction.returning(@)()
anotherFunction.returning()(someArg) # returns undefined to satisfy Issue 899

I don't think we need CoffeeScript to add syntax for things that uninhibited JavaScript already does well.

[Qard]

I don't know if I'd call that "well", looks pretty janky to me. Not to mention tha'd require setting the context on the calling end, which is super fragile.

[STRd6]

I think I misread the issue. I thought it was about being able to chain functions that may or may not have been written with chaining in mind. You're right that my comment won't be a more elegant form of a dangling @. I usually stick with return this for clarity.

[michaelficarra]

I usually stick with return this for clarity.

As you should, since standalone @ will soon be disallowed anyway. @Qard take note.

[Qard]

Yes, I've seen that before. I still think it's kind of a weird justification. Trying to make this and prototype behave similar seems odd to me, since they are two very different things in the first place.

[TrevorBurnham]

If there's no syntax for functions that return nothing (#899), there certainly shouldn't be a syntax for functions that return this. Ending a function with @ is perfectly nice.

@michaelficarra I'm still hoping standalone @ sticks around.

[aslilac]

@TrevorBurnham You took the words right out of my mouth.

Standalone @ can be really useful at times.

[wavded]

+1 on keeping the @ but really hope we can reconsider void function syntax of #899 for event handlers, async libs, like vows, it would be really handy

[jashkenas]

Here's the party line on some of the things mentioned here:

• Standalone @ will not be disallowed, for consistency's sake -- so you can keep using it -- but it will be considered poor style.
• In general, the natural return value of a function lies at the end of the function body. This is in line with CoffeeScript's function syntax, where the general scheme is input -> (points to) output.

We're not going to add a special function glyph to predetermine the return value of a function -- whether that return value is void, this, or something else, simply because it's putting the return value in the wrong place. When reading a function, the input should be at the beginning, the body should be in the middle, and the output should be at the end.