💭 [lint] suggested usage of async function

[ematipico]

This is an issue to track a suggestion from @samccone (#1118 (comment)); suggestion given while there was a discussion around enforcing await inside async functions.

Here's the suggestion of the rule

I would rework this rule to be a bit more nuanced, all async function calls should either be

1. prefixed with an `await`

2. consumed by another fn

for instance

ILovePromises(myAsyncFn());

That means that the following patterns would not error

await foo()
yay(foo);

but

foo()

would

I like this suggestion and I think we should implement it.

cc @bitpshr

[ljharb]

The problem with this suggestion is that, in the absense of type info, it forces otherwise synchronous function calls to take an unnecessary tick (by adding await), which isn't just slower, but might also break things if same-tick semantics are important.

[sebmck]

I am generally against lint rules that can't be reliably inferred with static information, even .then makes me a bit uncomfortable since we don't know that it's actually a promise. Although 99.999% of the time it will be, especially since "thenables" are an actual spec detail.

It would be nice to keep a track of lint rules that are only practical, or reliable, with the usage of type information so we can more appropriately justify investment in the future. Don't want that to be a blocker here for implementation but it's something we should keep in mind when deciding if a rule isn't reliable enough to be useful and a net positive.

[bitpshr]

Should this ticket be repurposed to be a list of rules that may be useful once proper type information is available @ematipico?