C++20 and beyond (cppwinrt v3)

[kennykerr]

cppwinrt v2 is based on C++17, which lacks a number of new features that may be of some benefit to the cppwinrt library. I'm starting to experiment with cppwinrt v3 and what it would look like to adopt some of the C++ language and library features introduced in C++20 and C++23. cppwinrt v2 already supports C++20 coroutines but some other features are harder to introduce without more substantial and breaking changes. Here's a starting list of what I'd like to see in v3. Feel free to comment on other features that you think might be beneficial.

C++20

• Three-way comparison - to simplify comparison generation
• Modules - to simplify and reduce build time
• Concepts - to simplify implementations
• Ranges - to simplify collections
• span - to replace array_view

C++23

• Deducing this - to simplify and reduce CRTP complexity & support the builder pattern

It should be clear that the theme is make things simpler and not just adding more bells and whistles. If we find that adding support for X makes things more complicated, then we'd be far less likely to adopt it. By themselves, the C++20 features aren't really compelling enough to spin up a v3 of cppwinrt, but C++23's "deducing this" feature could potentially move the needle so I'm thinking of target C++23 as the min version.

[sylveon]

The work in the modules PR I opened a while ago could be used, but I'd need to check if the compiler bugs I hit have been fixed.

However, there is still stuff that could be done to improve modules here. For example a single change in any API rebuilds the entire module which takes a solid 2-3 minutes on a fast machine. We should probably use module fragments (for example, one per top-level namespace) so that a change to APIs in Contoso.* doesn't cause the compiler to rebuild all of Windows.*.

Also, it obviously needs support for producing runtime components, as right now the modules code in cppwinrt only supports consuming.

Another question is if modules should be something that is always on. While I don't oppose that, some people might because it puts quite a migration burden on existing code.

I believe deducing this might help quite a lot with build times as well, so it may be worth making C++23 the min version.

[asklar]

I believe the last straggler compiler bug impacting modules was fixed recently, @Scottj1s will have more data on that.
Deducing this will make builder pattern a lot easier to implement/consume.

[Scottj1s]

@sylveon I've been building on your topic branch, working around a few module compilation issues. I've been working with the modules devs and the last blocker has now been addressed:
https://developercommunity.visualstudio.com/t/use-of-modules-with-cwinrt-winrtimplname-v-causes/1613181?from=email
When that fix is available in a preview, I'll validate and open a PR here.

I also raised the question of using module fragments and that's recommended.

Regarding migration, project templates are often opted into the latest features, whereas existing projects are defaulted off for safety. We can control both with a new project property.

[sylveon]

Great news! I believe exporting namespace std is not needed anymore either, but haven't tried.

[jlaanstra]

Let's make -opt the default.

[kennykerr]

Let's make -opt the default.

Great idea, we'll need to overcome the reasons why -opt is not always appropriate but I think that's doable. I also want to remove as many "options" as possible. It just adds so much cognitive and technical complexity.

[sylveon]

Yeah, we should also make fast ABI the default.

[kennykerr]

Yeah, we should also make fast ABI the default.

Although I originally implemented the fast ABI, I have serious doubts about its viability and thus far we've seen no adoption so I'm not inclined to think that it should be something we turn on by default or even support at all. It is incredibly complicated compared to the theoretical gains it provides to APIs in general.

[jonwis]

Fast ABI

Let's talk about this first - IIRC the blockers were that the main producers in Windows needed to turn on FastABI support, which was missing for a while. Types like XAML and Composition with lots of little interfaces and versions should benefit from this, yes? WinAppSDK sort of resets the XAML & Composition interface structure, but with our potential release cadence we'll be back into the "5 iterations of Button" by 2025.

Even if there's not wide public adoption of FastABI, in-Windows consumption seems like should be useful. The main wins were about binary size and runtime probing for interfaces, yes? I think we'd still want those. Maybe not a p0, but definitely still interesting.

I'd love to hear more about the state of FastABI in general, maybe in another discusison/thread.

Also, is there a timeline for when VS makes available and the OS repo gets support for the features under consideration?

[sylveon]

Yes I pretty much always believed XAML would be perfect candidate for fast ABI and am surprised it hasn't adopted it yet. Windows App SDK should also definitely look into it.

What IDE support is missing, specifically? I can turn on fast ABI from the C++/WinRT properties sheet in VS.

[kennykerr]

the blockers were that the main producers in Windows needed to turn on FastABI support, which was missing for a while

Not for a while. It has never happened.

Types like XAML and Composition with lots of little interfaces and versions should benefit from this, yes?

The fast ABI was designed for Composition, not Xaml. Composition never adopted it and there is no evidence that it would benefit Xaml due to its reliance on open hierarchies and cross-binary aggregation. I suspect that would break some of the assumptions that the fast ABI depends on and at the very least dramatically reduce any benefit.

Even if there's not wide public adoption of FastABI, in-Windows consumption seems like should be useful.

I am not aware of any adoption either inside or outside Windows.

The main wins were about binary size and runtime probing for interfaces, yes?

The chief benefit is a reduction in QueryInterface/Release calls, but only if such calls can be eliminated at compile time. An object size reduction is available but only if you drop backward compatibility. There are no other benefits and a great deal of complexity.