Hacker News Reader

Comment by GordonS | Hacker News Reader

Surely it's the same "virus"? Unless I'm mistaken, the async2 proposal wouldn't require any code changes, as it essentialy just moves compiler stuff to the runtime.

View on HN

They still need to interop the old async with the new async, without requiring recompilation of everything, otherwise it is going to be another .NET Framework to .NET Core, which is still ongoing.

The current generated state-machine mechanism is not going away any time soon. Instead, Roslyn as well as any other compiler that targets CIL is expected, when appropriate, to stop generating state machines and start generating specially annotated method calls recognized by .NET.

This means that all existing libraries will continue working as is, and newly written or existing code that is compiled against e.g. C# 14/.NET 10(?) can automatically opt into new mechanism without user intervention. The write-up does cover the considerations for interoperability between these two models as well.

In fact, this will make using async from other CIL-based languages much easier as the burden of capturing the state and suspending/resuming the execution will be on the runtime rather than language compiler authors.

The kind of scenarios where this kind of interop is put to test is when old code, without being recompiled, takes a subclass, an interface implementation, a member reference, a delegate, or a lambda, compiled with async2 model, as parameter, and everything works as expected.

Something that I hope they take into account, having new code calling into the old code, is the easy part of the problem.

Yes, we considered that and implemented a solution. Effectively, the runtime will generate thunk methods that will invisibly bridge between the two worlds. Calling (and overriding) regular async methods with runtime async methods will be stitched up by the runtime. The user will never see the difference.

Cool! Thanks for jumping in.

Reply on news.ycombinator.com