Support for named bag of promises

[acutmore]

The most common frustration I hit with Promise.all is that it only supports lists of promises, which doesn't scale well when starting multiple discreet tasks in parallel.

const [
  user,
  session,
  taskParams,
  config,
] = await Promise.all([
  getUser(),
  getSession(),
  getTask(),
  getConfig(),
]);

As the code grows and more things are added over time it can get harder to be sure that the names are lining up with the correct promise. If await.all had a grammar that added support for named promises I would find that very valuable. await.all [...] for iterator and await.all {...} for nominal.

const {
  user,
  session,
  taskParams,
  config,
} = await.all {
  user: getUser(),
  session: getSession(),
  taskParams: getTask(),
  config: getConfig(),
};

Refs: http://bluebirdjs.com/docs/api/promise.props.html

[ljharb]

That's a very tricky problem, and one that should be handled by a separate proposal - this is meant to be sugar for existing Promise operations. See https://github.com/ajvincent/proposal-await-dictionary for discussion of handling an object.

I'll close this as out of scope, until the language already has the capability of handling a dictionary of Promises.

[acutmore]

Fair enough that it might be out of scope but I think it should be kept in mind otherwise it might prevent future syntax possibilities here.

[ljharb]

I'm not sure how it would - if await.all mirrors Promise.all etc, then any changes to those APIs would work here as well.

Since Promise.all takes an iterable, I assume the only way it could also take an object is as an overload, which await.all would support - and if it were done with a separate method, there'd be a separate pseudoproperty on await.

[acutmore]

We do not necessarily need await.all to be sugar for Promise.all, it could have additional capabilities that increase its value.

await.all [...tasks] could map to await Promise.all(tasks) and await.all { ...tasks } could map to a hypothetical Promise.props.all(tasks). But not if the proposal is await.all exp mapping only to await Promise.all(expr).

As we are still in stage 1, it feels like this type of discussion on the design would be valuable.

[ljharb]

I think it's very critical that Promise syntax continue to never have any capabilities that Promise APIs do - iow, it's merely sugar for them. That held throughout a number of async proposals.

I also think that the major value prop of this proposal's syntax is the correspondence with the static Promise combinators.

I'll certainly reopen to continue discussion, since this would be a potential cross-cutting concern, but I don't foresee a different outcome.

[acutmore]

I'll certainly reopen to continue discussion, since this would be a potential cross-cutting concern, but I don't foresee a different outcome

thanks. Even if the outcome doesn't change, at least it would be a conscious outcome rather than incidental 🙂