I think sharing code through a static library of WinRT building blocks would be more flexible.
Oh definitely, I don't intend for this to be a replacement for !2298.. My motivation here is just for this to be a way to implement `IAsyncOperation<T>` by dogfooding the `Windows.System.Threading` module and reducing usage of Win32 primitives as much as possible (assuming that's a desirable goal for WinRT components :-)), and can possibly be the code for the static lib too (unless using COM modules from `dlls/` is frowned upon in static libraries).
Just had a quick look but it only seem to save ~50 LoC in cryptowinrt compared to the previous implementation, so I'm not sure it's worth the extra indirections and extra code?
Ideally, the `IAsyncOperation<T>` implementation code is generic enough, and can be boiled down to a macro implementation if needed. I think the LoC reductions are mostly cumulative as a result.
It's also not clear to me how `IAsyncOperationWithProgress` would be implemented with this
Yeah, I was thinking of keeping track of the progress handler from the outer `IAsyncOperationWithProgress` implementation with an additional wrapper like `struct async_operation`, but that would require guarding it with additional synchronization, which is suboptimal and defeats the purpose of not using on Win32 primitives in the first place.