Simplify proposal to exclusively syntactic sugar?

[schalkventer]

It might be worth, given the slowdown of progress on this proposal to rather advocate for an exclusively syntactical sugar approach on top of IIFEs?

For example:

const calculated = (() => {
  const a = 1;
  const b = 2;
  const result = 3;
  return result;
})()

can perhaps be expressed as ab abrriw function without arguments?

const calculated => {
  const a = 1;
  const b = 2;
  const result = 3;
  return result;
}

or something like this?

const calculated = !{
  const a = 1;
  const b = 2;
  const result = 3;
  return result;
}

This might not be the best syntax, but just as an example.

[ljharb]

If it's just sugar then it's not worth adding.

[mindplay-dk]

It's just sugar either way, isn't it? It's not like do-expressions, as proposed, enable you to do anything new? Unless I'm mistaken, they just provide new and more ergonomic ways to do things you can already do, right?

I personally find this very convoluted:

const calculated = (() => {
  const a = 1;
  const b = 2;
  const result = 3;
  return result;
})()

And this would be much clearer to me:

const calculated = do {
  const a = 1;
  const b = 2;
  const result = 3;
  return result;
}

It might be "just sugar", and you might think it's not worth adding because it's not very substantial?

To me, that would be a pro and not a con - this is simple and easy to understand right away.

Notably, it doesn't introduce the entirely new and foreign paradigm of implicit returns, which seem really out of place in JS. (if you really wanted to propose implicit returns, they should work consistently everywhere, not just in one corner of the language.)

The exceptions for break/continue/return aren't appealing either.

Having a simpler sugar would be nice for statements that typically stand alone as well, e.g. for try:

const calculated = do try {
  return mightThrow()
} catch (e) {
  return 'fallback'
}

It's potentially really good for type inference and type safety in TS in general.

It's also potentially much more ergonomic in JSX.

I think the ecosystem benefits of a simpler syntactic sugar might be worth considering.

A small feature can have a notable impact - I make annoying tradeoffs daily with JS/TS/JSX in expression contexts, where an inline if/for/try/etc. statement could have done exactly what I wanted without introducing a function.

This might be a much small and simpler feature, but that doesn't have to be a bad thing?

I think this idea might be underrated. 🙂

[schalkventer]

@mindplay-dk I wonder whether it is worth doing an experimental Babel, etc. plugin as a proof of concept.

At the moment I'm using a basic utility along the lines of:

import { iife } from '@/utils/iife'

const value = iife(() => {
   if (Math.random() > 0.5) return 10;
   return 20;
})

So that would then become the following:

const value = do {
   if (Math.random() > 0.5) return 10;
   return 20;
}

The transpilation should be trivial itself, however existing linting tools will be super unhappy.

Even you override linting settings or add a linting-specific plugin, this will still break type inference, etc. 🤔

[mindplay-dk]

I wonder whether it is worth doing an experimental Babel, etc. plugin as a proof of concept.

you've literally showed the whole thing with one simple example - the change itself is simple, not much to it.

what might be worth doing is exploring the idea - find real world practical use cases for IIFE's, or try to find or think of examples where something this simple would really help.

you could try writing an updated README as well for comparison - not the README really has much in the way of examples to explain why this feature is needed, so maybe think up more examples, and compare the examples between the two alternative approaches. I expect the simplified version would achieve most of the same things, but might look and work more like JS - that's just my gut feeling though, some work is required to (dis)prove it. 🙂