winrt::resume_foreground compile failed

[shelllet]

co_await winrt::resume_foreground(q);

when i clean up the solution and rebuild it, it still failes to compile .

I think Generated files does not appear to contain the overloaded function。

[kennykerr]

@btueffers I don't work on Project Reunion so assigning issues to me won't help much. Feel free to mention me (e.g. @kennykerr) if you need me to comment on an issue or PR.

@shelllet The C++/WinRT resume_foreground helper only supports a fixed set of dispatchers (not including the one in your error message). To support additional dispatchers, ProjectReunion/WinUI/WIL/your project would need to provide a helper function to do the same thing for the particular dispatcher you're using.

[sylveon]

Worth nothing that cppwinrt supports this type, but the support got broken due to it being moved to a different namespace in PR 0.8. See the changelog:

All types in the Microsoft.System namespace have been moved to the Microsoft.UI.Dispatching namespace, including the DispatcherQueue class.

So the base_coroutine_system_winui string in cppwinrt would need to be updated to account for this namespace change.

[kennykerr]

Well spotted. 😉

We can't change that as that may break existing code. And that's why we decided against supporting additional dispatchers. Components that ship their own dispatchers should just add a helper for C++ developers to use. If and when those APIs gets renamed, their accompanying helpers can simply be updated and versioned as a set.

[sylveon]

Ok it does seem like WinUI ships their own header for that, @shelllet try including <microsoft.ui.dispatching.co_await.h>.

However, I would argue needing to include a special header for this is certainly unexpected when compared to PR 0.5 and prior, as well as UWP, where just including the projection header was enough to get full co_await functionality.

Doing such a breaking change (the namespace rename) when PR was already deemed production ready is also a bit questionable :/

Also I don't know if setting the precedent of injecting custom stuff in the winrt namespace is something I would do (my approach would probably be adding an extension point instead), but it's ultimately your call.

@kennykerr would you be opposed to adding something like

#if __has_include(<microsoft.ui.dispatching.co_await.h>)
#include <microsoft.ui.dispatching.co_await.h>
#endif

to the cppwinrt output for Microsoft.UI.Dispatching? That way we keep the benefits of it being versioned with the rest of the API (as long as the file name doesn't changes), while keeping the behavior consistent with pre-0.8 PR and UWP (co_await just works(tm) when you #include the projection header)

[jonwis]

We're following semantic-versioning rules; 0.* releases are allowed to have breaking changes between them. What we'll do a better job on is tracking and reporting those breaking changes release-over-release. @andrewleader FYI.

We probably need a better way to deliver per-language/runtime "helpers" (C++/WinRT's co_await, C# extension methods on top of the normal C#/WinRT projections, traits for Rust, etc.) @BenJKuhn this is related to our recent conversation.

[riverar]

@jonwis If this was vanilla semver, I'd agree. But Microsoft announced Project Reunion 0.5 as stable and production-ready.

WinUI 3 - Project Reunion 0.5 is the first stable, supported version of WinUI 3 that can be used to create production apps that can be published to the Microsoft Store

Moving namespaces around is not compatible with those qualifiers, imo.

[shelllet]

Your style of dealing with the problem was so great ! I agree with Jonwis. Add to the changelog: The header file microsoft.ui.dispatching.co_await.h needs to be included, I think adding a note like this would be fine.。

[BenJKuhn]

@shelllet, @riverar, @jonwis, @kennykerr: the historic pattern for this in Windows is #include "windows.h". Is that an anti-pattern, or should we consider something like a #include "appsdk.h" as a catch-all starting point for C++ development? I'd love to hear folks thoughts.

Ben

[sylveon]

The issue with Windows.h is that it's required to do anything Windows-related, as it contains important macro definitions used in the rest of the headers. If appsdk.h becomes a thing, it should be possible to include individual components as well, without requiring to include appsdk.h and bring in the entirety of it just to use a certain component.

[tom-huntington]

If anyone's having problems with the +1.0 SDK see https://stackoverflow.com/a/70583555/11998382

#include <wil/cppwinrt.h>
#include <wil/cppwinrt_helpers.h>

co_await wil::resume_foreground(DispatcherQueue());