Exploring projecting WinRT async interfaces as custom Task types

[Sergio0694]

As part of CsWinRT 3.0 (see .NET epic here), we're exploring possible improvements we could do on the projected API surface for .winmd-s, now that this breaking change (CsWinRT 3.0 itself) would give us a unique opportunity to do so. A common point of friction has always been the way WinRT async interfaces are projected to .NET, ie. the following types:

• IAsyncAction
• IAsyncActionWithProgress<TProgress>
• IAsyncOperation<T>
• IAsyncOperationWithProgress<T, TProgress>

Currently, these types are just projected as interfaces (matching the .winmd definition). This has always been a pain point:

• They don't match what normal .NET code looks like at all, and we have to explain why
• You need to sprinkle AsTask calls all over the place to actually get a normal Task, whenever you need one
• When authoring, you can't implement such methods directly, as you can't have an async method returning those types

Note

The main reason why we haven't just used Task and Task<T> before is that doing so would lose a bunch of functionality exposed by those WinRT interfaces. Specifically, the fact you can attach some progress handler, and the other APIs defined on those types.

We'd like to explore addressing at least the first two points. One idea that came up was to define custom types that extend Task and Task<T>, so that we can have some projected types that are Task types, but also expose the additional APIs. Something like:

• WindowsRuntimeTask
• WindowsRuntimeTaskWithProgress<TProgress>
• WindowsRuntimeTask<T>
• WindowsRuntimeTaskWithProgress<T, TProgress>

Each of these would be a Task or Task, and also wrap a reference to the native async object, so that it can implement the additional APIs for its underlying interface (eg. Completed, Cancel(), etc.). You'd also not need any conversion methods to/from Task-s anymore.

The main problem with this is: we're not seeing any obvious way to actually define such a custom Task type. All the base Task constructors take some Action or Func<T>, which we wouldn't actually have in this scenario (we are wrapping a native object).

• Is there some way we're not seeing to extend these types
• Would this need some new APIs exposed to allow deriving?
• Thoughts on this idea in general?
• If we extended Task types, would this also possibly be beneficial with respect to async2? (cc. @VSadov)

Thank you! 🙂

cc. @stephentoub @jevansaks @manodasanW

[AustinWise]

This is not exactly what you are asking for (defining a new type that extends Task). But it's similar: you can define a new Task-like type that is returned from async methods using the AsyncMethodBuilder attribute. ValueTask is an example of a Task-like type implemented this way. Docs:

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-10.0/async-method-builders

https://github.com/dotnet/roslyn/blob/main/docs/features/task-types.md

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/attributes/general#asyncmethodbuilder-attribute

[VSadov]

If we extended Task types, would this also possibly be beneficial with respect to async2?

It will be treated as a custom Task-like and will work, but will not be optimized in a way that an async2 function that awaits another async2 function.

The whole point that you cannot use regular Task because your asynchronous API is sideeffecting in various ways, indicates that it cannot be optimized away.