How cppwinrt.exe tool know which C++ version to use to generate the headers from .winmd files?

I don't see any switch to specify the "C++ version" in the cppwinrt.exe tool !

(my fundamental assumption is cppwinrt.exe tool binds the C++ 17 syntax to the ABI, I can't figure out how it can bind C++ 20 or future newer versions syntax )

Similarly, the cswinrt.exe tool from C#/WinRT projection generates .cs files from .winmd files. The same question applies , How does the cswinrt.exe tool know which "C# version" to use to generate the .cs files ?

I don't see any switch to specify the "C# version" in the cswinrt.exe tool either !

end goal : is to understand how "language versions" fit in the WinRT language projections

Solution

The cppwinrt.exe tool doesn't allow you to specify a C++ language standard. It simply defaults to C++17, with the ability to opt-in to newer language features by way of feature test macros.

The result is that the generated header files can be compiled with any C++17 compiler, or a compiler that supports a later language version.

At this time (C++/WinRT version 2.0.210922.5) there are four C++20 features in use:

C++20 coroutines, guarded by an #ifdef __cpp_lib_coroutine directive (though that is really just deciding on whether to include the coroutine header file from the experimental/ directory or not; coroutines have been supported since VS 2015).
C++20 modules. This isn't guarded as clients need to explicitly opt-in to using winrt.ixx through an import declaration.
Support for C++20 ranges (introduced in 2.0.210329.4). This is an interesting one in that none of the code changes require a C++20 compiler. The feature simply lights up for clients using a C++20 compiler when they use the <ranges> standard library header.
C++20 std::format (introduced in 2.0.210922.5), guarded by an #ifdef __cpp_lib_format directive.

At a fundamental level, C++/WinRT is just a C++ library. As such it can employ any technique that's suitable to providing language-adaptive implementations.

I don't know how C#/WinRT operates internally, nor C# for that matter, so I cannot comment on that.