await functioncall versus async functioncall, Type augment key names, using [K+"Async"] in keyof T,

[wesleyolis]

Suggestion

Allow one to change the name of keys, so that when we perform promisification or any other
structural enhancement were values are wrapped in a promise, we can change the key name to have
a suffix 'Async' added.

I find that I am not able to clearly communicate the functional call execution behaviour at runtime, because the Async keyword needs to be present in the function name, just like in C# and how it has been done. C# in my opinion made the right choice, unless you able to provide alternative on how to clearly communicate the following cases. I use a little bit of C# terminology of a task here, because allows to communicate all the different execution behaviours that exist if one were to take a step back away from language specifics.

The one thing to remember here is that when I read the code and would like to audit and vet it, then I would like to easily be able to distinguish and identify function calls and code us-usage that are correct.
I have been in projects, were their is functional and object orientation mess, one found, one self having to use the compiler to assit and inspect the types or jump to the functions the whole time, which is so slow. I the came up with simple suffix conventions to make it easier and quicker, to vet the code. See that my thoughts on what I did in c++ here Coding Standards and Conventions.
This is one the main reason and motivations for me that, I want to be able to read code and know whats going on, with out having to rely compiler enhancements navigation functionality, slow and time consuming mouse hover operations.

(I change my mind by the end of this article after walking tought the alternative, which rather different approach, so given the way the current language is, I feel the right async suffix is best, since I can't change the language. Since both these views requires a language change, the suffix being a small one I would feel, versus async functionCall discussed below, I feel that it would be up to the community to weigh in the pros and cons, including C#, since they already support tasks. At least Async suffix can communicate difference then between task and true Async IRQ function, so maybe all of this would be best to communicate clearly different expected execution behaviours.)

One could argue that async suffix is not needed, and one assumes that every function runs as asyncly, if that was true, then their would be no need for the await key word, because we would probably want to await every single call to be able to be able to chain or sequence set of function calls to write anything sensible, were the computation is dependent on the previous executed statement. Then one could basically say not just remove await, as it is pointless to await every function it's just overly verbose.
If I were to remove it, then we need a new keyword to communicate which function we actually want to intentional run asyncly. "async runMyMethod()".

If one was to assume that every function potentially could run async, then all those function that don't actually run async and would run immediately syncly on the current thread, would offer no benefit, just create more verbosity in the code.
The only benefit would come, were promise(task) could be run on other processors threads that execute in parallel, which with new versions of node looks to support, were methods that are not async(Promised) that they are then called with the async keyword, the compiler would then potentially convert the function to a promise task, The compiler could also choose to inline certain async function call statements, because binary code execution task wrapping overheard, would make it slower.

Conclusion

I feel the move to "async functionCall()" togatheir with having the Async suffix on function names would clearly communicate the different expected behaviours of cases, such as being able to identify a simple task execution versus async IRQ Task, while reducing the verbosity of the await statement usage and having just a single keyword async, instead of like createTask and await.

One additional motivation, is forgetting/missing the use of await keyword, in which things can be quite fun!! later on, when bring everything to gather. Yes it was some fun, learning pitfalls of await :-(

I feel await is like wanting to negate the whole world, when most of the time, when we write code and smaller functions that are naturally sync code. I feel the positive cases keyword dictate when want something to be run as async would be much better, like const mmm = async callme(); The compiler could then emit warnings, if some were below this function call their is async code being execute sync.
It would be much simple to fix and just add the missing async in front of functions and expand the scope of async code from compiler warnings to improve speed. It would also make debug async code simpler, just turn it off and on.

Use Cases:

Potentially syntax way A

type ExtractWithFactoriesLazyLoaded<T> = {
[K, [T[K] extends factory ? K+"Async" : K] in keyof T] :  T[K] extends factory ? factory.interface : T[K], 
}

Potentially syntax way B

type ExtractWithFactoriesLazyLoaded<T> = {
[K in keyof T] :  [T[K] extends factory ? K+"Async" : K], T[K] extends factory ? factory.interface : T[K], 
}

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)

[MartinJohns]

Duplicate of #12754

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.