I've now had a chance to systematically look at how our code fares under PS's implicit return. Thanks to Scott for being the guinea pig for the rest of us. I like it! I do have a few questions/issues. I'll send them in separate emails, I guess.

PS now tries to insert a default "return null;" statement in functions that would formerly have returned nothing, i.e. whose return values would have been undefined. I am not convinced that this buys us much. We've always treated NULL and UNDEFINED as conveying the same information when returning from a function. I recognize not everyone would share this interpretation.

The trouble with explicit "return null" is that you end up with things like the following example taken from our code (stripped-down for brevity):

(defun blep (ss x y)
      (when foo?
        (awhen (bar)
          (destructuring-bind (c r) it
            (when (!null c r)
              (awhen (baz)
                (when (blah it)
                  (unless (blee)
                    t))))))))

=>

function blep(ss, x, y) {
    if (foowhat) {
        var it = bar();
        if (it != null && it !== false) {
            var c = it[0];
            var r = it[1];
            if (c != null && r != null) {
                var it27537 = baz();
                if (it27537 != null && it27537 !== false) {
                    if (blah(it27537)) {
                        if (!blee()) {
                            return true;
                        } else {
                            return null;
                        };
                    } else {
                        return null;
                    };
                } else {
                    return null;
                };
            } else {
                return null;
            };
        } else {
            return null;
        };
    } else {
        return null;
    };
};

I wish PS would avoid generating all those "return null"s when the only thing we need is the "return true".

Note also that PS is not *always* returning null; there are cases where the old undefined behavior still exists:

(ps (defun foo () (dolist (a b) (blah a))))
=>
"function foo() {
    for (var a = null, _js_idx27540 = 0; _js_idx27540 < b.length; _js_idx27540 += 1) {
        a = b[_js_idx27540];
        blah(a);
    };
};"

Personally, I think this is fine and would rather see all functions behave this way. That is, if I put a NIL in a tail position in my code, I should get "return null" and otherwise no explicit return in JS. We can't factor the null vs. undefined distinction out of PS altogether; it's too engrained in JS. Anyway this issue is, to my mind, distinct from the implicit return feature as such.

What am I missing?

Daniel