When trying to port over some applications to coffeescript, I had to revisit a whole lot of my functions to add in an empty return; line after code like:

    test: (m) ->
      m(i) for i in this.set

I probably should have expected that, sure, and if you don't have to deal with too much data it probably won't matter.

Certainly, you need to keep in mind the return value of a function while you're writing it -- if you don't want to return any value, then just "return". And it's definitely something that you need to keep more in mind while porting JS than when writing code from scratch. But given all that, would you really prefer explicit returns in CoffeeScript?

What I was trying to express was that I don't generally run into this issue in ruby because the similar looping constructs don't behave this way, and don't carry the same kind of unexpected side-effects:

    def test(lst) lst.each{|i|do_stuff(i)} end

    def test(lst) lst.map{|i|do_stuff(i)} end

The only situation where I get into the problem is with looping, and after some time using CoffeeScript, only rarely, so it may just be one of those things you have to put up with. Still crops up occasionally after refactoring though.

I would not want to get rid of implicit returns, and would far rather continue dealing with the loop problems than that. Would just love it if those weren't the only options.

I'll guess it's because speed is less of a concern when programming in Ruby.

if you don't want to return any value, then just "return".

Yes, but that leads to clutter and goes against one of the selling points of CoffeeScript.

Previous discussions on this:

http://github.com/jashkenas/coffee-script/issues/1401

http://github.com/jashkenas/coffee-script/issues/899

I listed some of the pitfalls with implicit returns at the following CS issue: https://github.com/jashkenas/coffee-script/issues/899#issuec...

Besides that, I still get feelings of discomfort when thinking about rewriting JS to coffeescript when knowing that the compiler will just write it as JS again.

EDIT: Tried it. In this case it seems to works.

    $.ajax(url, {
      data: data,
      contentType: contentType,
      success: success,
      error: error
    });

    $.ajax url, {data, contentType, success, error}

    {spawn, exec} = require 'child_process'

This is probably just a familiarity thing and I would get used to it, but compared to all of the other changes in the video which I think are pretty clean that stood out to me as a bit... iffy?

    for {handler, context} in @events[topic]
      handler.apply context, args

  if(!foo) {
    maybeDoSomething();

    return;
  }

  bar();

The unless statement makes the early exit seem like the default action rather than the exceptional action it (hopefully) is.