Possible alternative syntax than the meta-property-like syntax?

[Jack-Works]

ideas welcome!

Checklist for the syntax:

• No syntax ambiguity, please check it with the following cases:
  • <syntax> [promise] should not have ambiguity with a member access expression
  • <syntax> (iterable) should not have ambiguity with a call expression
  • No other syntax ambiguity
• No ASI Hazzard

[ljharb]

await all <expression>

[Jack-Works]

await all <expression>

Then you get the syntax ambiguity

await all (expr)

Means await all (expr) or await all(expr)?

[hax]

Assume the syntax will be await[X]all and X should be one character or it will be too long, these combinations are possible:

await%all
await^all
await&all
await*all
await|all
await\all
await:all
await,all
await?all
await.all

If we rule out the binary operators (it seems we'd better save them for possible unary/sigil usage), we will only have

await\all
await:all
await,all
await?all
await.all

And I feel only await:all could be an alternative.

[ljharb]

I agree out of all of them, only . and : would feel aesthetic to me. However, await:all is a labelled statement where await is the label and all is an identifier, so I don't think that's an option.

[hax]

await is not allowed as label in module or async context. So I believe it's still an option :-)

[ljharb]

oh true, since this proposal would only apply in an async context or a module. fair point.

[zhangenming]

better await:all

[stiff]

I'd prefer to have normal functions instead of obscure syntax bloat.

If some helper is used a lot you can alias it and avoid typing Promise.:

const all = Promise.all;

await all(users.map(...))

Another option is to move .all to Array:

await users.map(...).all()

It offers lots of opportunities, but it requires some careful investigation.

[ljharb]

@stiff the problem is that users don't use them when it's not syntactic. await is easy to overuse, when await.all would be much more correct and performant.

[stiff]

Well I find it hard speaking for abstract users, but if performance is satisfactory without any .all's then who cares, but if not user will learn something about how things work.

Probably there is some risk that some people will just claim that js is slow instead of suspecting any misuse. On the other hand there is a risk that even bigger number of people will get scared of huge selection of similar syntax constructs that they have to understand before doing something.

[Jack-Works]

@stiff the problem is that users don't use them when it's not syntactic. await is easy to overuse, when await.all would be much more correct and performant.

Actually IMHO most developers won't use security/performance enhancement regardless it is syntactic or userland if it is not a default option.

e.g. people always use x[key] = val not defineProperty and accidentally triggers __proto__ setter. await.all is a shortcut for developers who already have consciousness of the performance problem of serial async operation