Runtime: Proposal, async, await, promise, holistic, language improvement tweak, with idea of were Javascript, TypeScript, nodeJS, c# have and are heading, to simplify things

[wesleyolis]

Hi,

I feel that it would be a good thing that dotnet be aware of this proposal that will affect both typescript and javascript in the future as they may want to contribute at a technical level to any insight they may have, because this has been done with a focus on the bigger picture of all languages, however, small the little roll they play, it also suggestions that c# may follow suit with this proposal.

tc39/ecma262#1258

Document:

https://docs.google.com/document/d/1QigfqvlM2vMNl-4szjuPj9tFXIQle2zsbrsnze9bAIU/edit?usp=sharing

[karelz]

@wesleyolis can you please be more specific? Short description of the idea you want in CoreFX? Or are you seeking support for your idea in other communities?

[wesleyolis]

Hi,

I have come to realise the the language pattern of async/await, that allows
us to flatten the programming structure to more sync style, has a slight catch, which has potentially been overlook, which is across the board of all languages..

So I am sharing it with all communities, in hope that one these communities comes back to me
who is able to understand this. So far C# is the only one, i have now also tried to share with rust community, since still working on there await/async spec.

I am trying to highlight a small function constraint pit fall, that needs to be removed for being able to use await in a function body to await a function that return type is async. Their is another small, thing but that should be made clear in the document, were I say you need to ask yourself the question.

That what all of this comes down to at the end of the day of me exploring the space in the document, as well get deep understand for the pattern in may differ implementation. Were c# implementation of the pattern is with tasks, typescript, is Promise/BlueBird.., CpuAsyncRegister, IOAsync

What I have tried to do is provide programmatic case support to illustrate why this is a problem.
I think the final way I would word things in the documents conclusion, makes it clear, that we current trying to communicate intrinsics internal of function body that is encapsulated away, in a cascade fashion, to the top level.

The async/await pattern is great, the problem is that for someone to await something in the body of a function it has been made the requirement that that function be made async, which then intern case a cascade all the way to the root, cause everything return type to be converted to async/aysncHandle, with all the wrapper over head of the async implementation specific details code generation.

I have further tried to explorer the pattern to highlight see their be any other problems may arise, if be used in other context and implementations later on. That is the section on XSync, RSync, ISync, were just explorer the avenue to see were would end up, get more insight into the domain of the problem.

Does this help make it clearly, what I am trying to achieve and communicate to all the communities about the pattern pitfalls, I have come to experience, which I have tried to provide support for my feeling, with support of concert arguments as pros and cons as to why the change is needed.

Note that the change, as far as I can see would not break anything current existing behaviour, just be less overhead of code generation, maybe one two slower function, which emit compiler warnings for they easily be fixed.

[wesleyolis]

The one other thing to mention is that await/async was ment to flatten callback hell for some languages or that styles of writing code to a flatted approach. Which is what it archives, but I feel we can further improve on things. Right now it allows with the constraint that all the code be chained, just by presenting it in a different way, but by removing the constraint for await, we can be more intelligent and optimize and reduce the code generation overhead, which the compiler could actually optimally be figuring out and merging chains in the back ground in single chains of code. The change allows encapsulation to be returned to the language, as well it being less verbose, by removing the constraint and allow the compiler to figure it out, were we just make the major parts of the code async, that are important, not everything, which allow us to communicate important differences between sections, versus current approach were everything becomes async.

[karelz]

I am still lost at what is the purpose of the issue. I see signs of potentially some suggested improvement - looks like it is targeted at compiler overhead. I also see signs of "I want to have discussion to better understand the problem space".
If you have a proposal in mind, I'd suggest to write crisp short description of your proposed suggestion. In such case, please specify what kind of improvements it is targeting (just compiler overhead - if yes, how much and why does it matter / why does it justify a change).

[wesleyolis]

@karelz I will get back to you soon sorry. Just many issues problems to solve, see if I can make it even clearly for everyone to understand my perspective.

[stephentoub]

I'm going to close this as non-actionable. If/when the issues can be distilled into something concrete, new issues should be opened. Thanks.