IIFE Statements & Expressions

💡 Ideas
42

Yep, that's one massive thought process. :-|
I actually just deleted a post about implicitly returning blocks because endless problem cases came to mind as soon as I considered it.
Using a new, non-existent syntax is just easier than changing the meaning of existing code.

@7ombie I agree that it doesn't look good, and that keyword looks much better than parentheses.

Here's an evil suggestion: bring back with recontextualized. >:-)

break label with expression;
break with expression;
break label;
break;

Now, when people try to Google with, they can barely even find documentation on its deprecated behavior.

1 Like
43

@theScottyJam - Thank you for the link. Much appreciated.

@0X-JonMichaelGalindo - IIUC, with-statements are completely illegal in Strict Mode (but they kept the keyword reserved), so with could be used for new syntax (and break with is illegal currently anyway). I don't think old with-statement docs would be an issue. Everyone reads MDN, which generally preempts confusions and conflations really well, pointing people in the right direction.

1 Like
44

Thinking some more about @theScottyJam's idea of opting into making specific statements expressions (as generalizing would introduce too many edgecases), I was considering what we would actually want to do with these expressions in practice.

There are quite a few places where JS takes an arbitrary expression where we wouldn't want users shoehorning some big block of code there. Having an if-else block as a default argument, for example. CoffeeScript taught us how far people will take this stuff, if you let them.

With that in mind, it may be worth shortlisting the cases, like assignment, where it would be useful to have a block as an expression, then create specific grammars for those cases (var-if, let-if, const-if etc).

So, you could do this:

let x = if (predicate) { 1 } else { 2 }

But, you could not do this (unless it was specifically added):

let x = [1, 2, if (predicate) { 3 } else { 4 }, 5];

This is not a complete solution, obviously - just food for thought.

45

Would it be possible to do something like this?

( animate => () {
    requestAnimationFrame(animate);
    graphics.render();
})();
46

Yes, but you have a syntax error - animate => () { doesn't make sense, you probably either want animate => { or animate => () => {.

1 Like
47

I think the idea is that syntax would name the arrow function so it can be called recursively

1 Like
48

ah, then no. imo arrow functions aren't meant to be used for recursion, precisely because they don't have a self-reference like that.

1 Like
49

how can I do this? how could this be done?

50 
const animate = () => {
    requestAnimationFrame(animate);
    graphics.render();
};
animate();

Or with a y-combinator inspired helper:

function rec(f) {
  return function g() { f(g); };
}

rec(animate => {
    requestAnimationFrame(animate);
    graphics.render();
})();;