Discuss
  • Support () => {}() syntax?

Support () => {}() syntax?

# Olivier Lalonde (8 years ago)

I occasionally write IIFE to avoid introducing let variables, e.g.:

const thumb = ({ width, height }) => {
  const { w, h } = (() => {
    // if either width or height is set, don't set any default
    if (Number.isInteger(width) || Number.isInteger(height)) {
      return { w: width, h: height }
    }
    return { w: 400, h: 400 }
  })()
  // ...
}

One annoyance is that arrow functions must be wrapped inside parens in order to be called. In other words, you can do (() => {})() but not () => {}(). The latter syntax is less verbose but is not supported.

I understand that the short style, e.g. val => val + 1() or val => (fn())() would be ambiguous but I don't believe the () => {} style would

be. Of course it gets a bit ambiguous when you get () => () => {}() but

that form isn't very common for IIFE.

Just wondering if this has been discussed before.

# Michał Wadas (8 years ago)

Similar proposal is already here, do expressions.

# Rick Waldron (8 years ago)

On Thu, Sep 29, 2016 at 3:14 PM Michał Wadas <michalwadas at gmail.com> wrote:

Similar proposal is already here, do expressions.

Additionally...

On 30 Sep 2016 12:06 a.m., "Olivier Lalonde" <olalonde at gmail.com> wrote:

I occasionally write IIFE to avoid introducing let variables, e.g.:

const thumb = ({ width, height }) => {
  const { w, h } = (() => {
    // if either width or height is set, don't set any default
    if (Number.isInteger(width) || Number.isInteger(height)) {
      return { w: width, h: height }
    }
    return { w: 400, h: 400 }
  })()
  // ...
}

Why introduce the function and cognitive overhead?

const thumb = ({ width, height }) => { const w = Number.isInteger(width) ? width : 400; const h = Number.isInteger(height) ? height : 400; // ... }

Either way, do expressions are what you're looking for.

# Olivier Lalonde (8 years ago)

Thanks, I wasn't aware of do expressions.

Why introduce the function and cognitive overhead?

Not that it really matters (I was just giving an example) but your alternative isn't achieving the same thing, which is to set a default to width and height if and only if neither height or width is set. (e.g. thumb({ width: 100 }) should set w = 100 and h = undefined not w = 100 and h = 400 but thumb({}) should set w=400 and h=400.

Anyways, I'll try to find out what those do expressions are about.

# Olivier Lalonde (8 years ago)

Do "do expressions" support the "await" keyword?

# Kevin Smith (8 years ago)

Ideally there will be an async version of do expressions, which evaluate to a promise:

let promise = async do {
  await something();
};

(BTW, if we get such a thing, we might not really need top-level-module-await...)

# Allen Wirfs-Brock (8 years ago)

An HTML attachment was scrubbed... URL: esdiscuss/attachments/20160930/315e704e/attachment

# Tab Atkins Jr. (8 years ago)

On Fri, Sep 30, 2016 at 7:23 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

On Sep 30, 2016 6:10 AM, Kevin Smith <zenparsing at gmail.com> wrote:

Ideally there will be an async version of do expressions, which evaluate to a promise:

let promise = async do {
  await something();
};

(BTW, if we get such a thing, we might not really need top-level-module-await...)

+1 !!

Aw dang, yeah, I really like that. (Obviously the example given is trivial, as just calling something() directly would give the exact same result, but being able to do more complicated stuff with the result means inline promise-chaining without having to asyncify your whole function!)

# Olivier Lalonde (8 years ago)

I noticed the proposal was made about 5 years ago but is still in stage-0. Is there anything holding it up?

# Bradley Meck (8 years ago)

To clarify top level await is a synchronization point for module loading. While I do think do expressions and do async have values, I don't think they fit the use case of top level await.

# Isiah Meadows (8 years ago)

Yeah... A top level async do expression would be nice, but it doesn't cover conditional imports very well (especially when exported values depend on what's imported, which I've done before in CommonJS).