We’re pleased to announce the availability of C++20 support for C++/CLI
in Visual Studio 2022 v17.6. This update to MSVC was in response to
feedback received from many customers via votes on Developer
Community
and otherwise. Thank you!

In Visual Studio 2022 v17.6, the use of /clr /std:c++20 will no
longer cause the compiler to emit a diagnostic warning that the compiler
will implicitly downgrade to /std:c++17. Most C++20 features are
supported with the exception of the following:

• Two-phase name lookup support for managed templates. This is
  temporarily on hold pending a bugfix.
• Support for module import under /clr.

Both the above are expected to be fixed in a near-future release of
MSVC.

The remainder of this blog post will discuss the background details,
limitations, and caveats of C++20 support for C++/CLI.

Brief history and background of C++/CLI

C++/CLI was first introduced as an extension to C++98. It was specified
as a superset of C++98 but soon with the introduction of C++11, some
incompatibilities appeared between C++/CLI and ISO C++, some of which
exist to this day. [Aside: nullptr and enum class were originally
C++/CLI inventions that were migrated to ISO C++ and standardized.]
With the further introduction of C++14 and C++17 standards, it became
increasingly challenging to support the newer language standards and
eventually due to the effort required to implement C++20, we decided
to temporarily limit standard support to C++17 in /clr mode. A
prime reason for this was the pause in the evolution of the C++/CLI
specification, which has not been updated since its introduction and
therefore could not guide the interaction of C++/CLI features with the
new features being introduced in ISO C++.

The design rationale for C++/CLI is spelled out in this
document.

Originally envisioned as a first-class language for .NET, C++/CLI’s
use has primarily fallen into the category of interop, which includes
both directions from managed to native and vice versa. The demise of
C++/CLI has been predicted many times, but it continues to thrive in
Windows applications primarily because of its strength in interop, where
it is very easy to use and hard to beat in performance. The original
goals spelled out in the C++/CLI Rationale were:

1. Enable C++/CLI as a first-class programming language on .NET.
2. Use the fewest possible extensions. ISO C++ code “just works” and
   conforming extensions are added to ISO C++ to allow working with
   .NET types.
3. Be as orthogonal as possible: if feature X works on ISO C++ types,
   it should also work on C++/CLI types.

With the specialization of C++/CLI as an interop language, the ECMA
specification for it was not updated to keep up with fast evolving
.NET features with the result that it can no longer be called a
first-class language on .NET. While it can consume most of the
fundamental types in the .NET base-class library, not all features are
available due to lack of support from C++/CLI. This has resulted in both
/clr:safe (allow only the “safe” CLS subset of CLI, disallowing native
code) and /clr:pure (compile everything to pure MSIL code) to be
deprecated. The only options supported currently are /clr, which
targets the .NET Framework, and /clr:netcore which targets NetCore.
In both cases, compilation of native types and code, and interop are
supported.

Goal (2) was originally achieved nearly perfectly in C++98 but newer
versions of ISO C++ caused MSVC to deviate from this goal.

With regard to goal (3), C++/CLI was never specified or implemented to
the required level of full generality to satisfy this goal. While some
features such as templates were made orthogonal to ISO C++ and managed
C++/CLI types, the full generality of features such as allocating
managed types on the native heap with new, allowing managed types to
embed in native types, etc., were not specified by the ECMA
specification. This lack of support turns out to be fortuitous and
allows us to move forward with implementing support for newer ISO C++
Standards.

C++20 support for C++/CLI

While C++14 and C++17 were mostly incremental updates to C++11, as far
as the core language is concerned, C++20 is a large change because of
features like concepts, modules, and coroutines. While coroutines
aren’t yet pervasive, concepts and modules are already in use in the ISO
C++ Standard Library.

Generally speaking, we need support from the .NET runtime whenever the
language introduces a new feature which has a runtime impact in the area
of implicit P/Invoke
interop.
Two examples from C++11 are move constructors and noexcept. The .NET
runtime’s P/Invoke engine already knew how to call copy constructors
when objects were copied across the managed/native boundary. With the
introduction of move constructors, types like std::unique_ptr were
handled incorrectly in interop because they have a move constructor
instead of a copy constructor. Handling this correctly required adding
functionality to the P/Invoke engine on the .NET side and generating
the code and metadata to make sure it was called appropriately. For the
noexcept case, we still don’t have a correct implementation available.
While we handle noexcept correctly in the type system, at runtime an
exception crossing a function with a noexcept specification does not
result in program termination. Implementing this would, again, require
teaching the .NET runtime how to handle such cases but due to no user
demand to handle this correctly, it has been left unimplemented.

We wanted to avoid requiring new functionality in the .NET runtime
since doing so is time consuming and requires expensive updates, so to
add support for C++20 to C++/CLI, we followed this general principle:

Separate C++/CLI types from new C++20 features but allow all possible
C++20 features with native types in a /clr compilation.

To achieve this, the implementation of C++20 support in C++/CLI follows
this scheme:

• All native code in a translation unit is compiled to managed MSIL,
  with the exception of code having these constructs in it:
  1. aligned data types
  2. inline assembly
  3. calls to functions declared
     __declspec(naked)
  4. references to __ImageBase
  5. functions with vararg (...) arguments
  6. __ptr32 or __ptr64 modifiers on pointer types
  7. CPU intrinsics or other intrinsic functions
  8. virtual call thunks to virtual functions not declared
     __clrcall
  9. setjmp or longjmp
  10. coroutines

  With the exception of coroutines, the above list has already been
  the case for compilation to native in prior versions of MSVC. All
  semantics conform to ISO C++ semantics, as before, the only
  difference being that the compiler emits managed instructions.
  Native types are emitted out to metadata as empty value classes with
  a given size, just to provide tokens for type names when they’re
  used in function signatures. Otherwise, they remain a black-box to
  the runtime and are handled entirely at the byte level by the
  generated managed code.

• Conformant (two-phase) name lookup ([temp.res] in ISO C++) is
  enabled in native templates in /clr compilations. Previous
  versions of MSVC forced the user to specify /Zc:twoPhase- when
  using /clr and any flag that implied ISO C++ name lookup
  semantics.
• Coroutines are implemented by compiling all coroutines to native
  code. This requires no new support from the .NET runtime and uses
  the native runtime support. The disadvantage is that all calls to
  coroutines are interop calls that have the transition and
  marshalling overhead.
• Allow concepts to interact only with native types. This is another
  violation of the “orthogonality” goal mentioned above. The exception
  is C++/CLI types that have a 1-1 mapping with native types such as
  System::Int32, etc.
• Allow import of modules but not export from translation units
  compiled with /clr. In a similar vein, module header units cannot
  be generated in a /clr compilation but may be used in one. This
  restriction is because the module metadata format is based on the
  IFC specification, which has no support for C++/CLI types.
• Allow all Standard Library headers to compile with /clr and
  C++20. Some headers had previously been blocked off from being
  compiled as managed because they included ConcRT parallel
  programming headers as a dependency, while some, like ,
  had no support in .NET. The dependency on ConcRT is now removed
  and headers previously forbidden from inclusion with /clr have
  been updated. Note: some of these headers are still forbidden from
  inclusion in /clr:pure mode.

No attempt is being made to fix the below pre-existing issues. If there
is user demand, these can be handled separately in the future.

• Lack of noexcept support from .NET, as explained above.
• enum class has differing meanings in C++/CLI and ISO C++. This is
  currently resolved by treating such declarations as native enums
  except when preceded by an access specifier (as C++/CLI allows).
• nullptr has differing meanings in C++/CLI and ISO C++. In cases
  where this matters, __nullptr is provided to mean the ISO
  C++ nullptr value.

Going forward, we plan to use the same strategy to support future ISO
C++ versions: compile constructs that have no support from .NET to
native code and keep the C++/CLI and ISO C++ type universes separate. In
the rare case where a new mechanism is required for marshalling types
across managed/native boundaries, we shall require new support from
.NET. Historically, this has not happened since C++11.

Examples

The below examples illustrate how C++20 constructs are being handled in
C++/CLI.

Coroutines

There are no restrictions on coroutines. They may be used in their full
generality with the understanding that the coroutines themselves are
always compiled to native code.

Consider the below program fragment:

generator answer()
{
    co_yield move_only(1);
    co_yield move_only(2);
    co_yield move_only(3);
    move_only m(4);
    co_return m; // Move constructor should be used here when present
}

int main()
{
    int sum = 0; 
    auto g = answer();
    for (move_only&& m : g)
    {
        sum += m.val;
    }
    return sum == 6 ? 0 : 42+sum;
}

Inspecting the generated IL for this, we can see this IL sequence:

IL_0000:  ldc.i4.0
IL_0001:  stloc.2
IL_0002:  ldc.i4.0
IL_0003:  stloc.0
IL_0004:  ldloca.s   V_8
IL_0006:  call       valuetype 'generator'*
              modreq([mscorlib]System.Runtime.CompilerServices.IsUdtReturn)
              modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
              answer(valuetype 'generator'*)
IL_000b:  pop

together with:

method assembly static pinvokeimpl(/* No map */) 
        valuetype 'generator'*
        modreq([mscorlib]System.Runtime.CompilerServices.IsUdtReturn)
        modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl) 
        answer(valuetype 'generator'* A_0)
                           native unmanaged preservesig
{
  // Embedded native code
} // end of method 'Global Functions'::answer

showing that answer() is a native method and the call to it in the
above MSIL disassembly fragment is an interop call. This is shown only
for exposition and the user has to do absolutely nothing to make it
work.

Concepts

Since concepts are a mechanism to perform computations on types at
compile time, there is no runtime component to be supported by .NET.
Further, concepts “disappear” once templates are specialized and
templates have been supported for C++/CLI from the outset. There are two
kinds of templates supported in C++/CLI, ISO C++ templates and managed
templates whose specialization results in managed types. We have made
the choice to keep all managed types separate from concepts and this
includes managed templates. Any attempt to mix managed types and
concepts results in a failed compilation with diagnostics. Note that
this excludes types like System::Int32 which can be mapped directly to
native types, but boxing of such types is also excluded from interaction
with concepts.

#include 
#include 
template
void Swap(Swappable& s1, Swappable& s2)
{
    s1.swap(s2);
}
struct SwapMe
{
    int i;
    void swap(SwapMe& other) { std::swap(this->i, other.i); }
};
value struct SwapMeV
{
    int i;
    void swap(SwapMeV% other) { auto tmp = i; i = other.i; other.i = tmp; }
};
int main()
{
    SwapMe s1, s2;
    Swap(s1, s2);
    SwapMeV s1v, s2v;
    Swap(s1v, s2v);   // error C7694: managed type 'SwapMeV' 
                      // used in a constraint definition or evaluation
                      // or in an entity that uses constraints
    // Boxed value types
    int ^b1 = 1;      
    int ^b2 = 2;
    Swap(b1, b2);     // error C7694: managed type 'System::Int32 ^'
                      // used in a constraint definition or evaluation
                      // or in an entity that uses constraints
}

In the above example, the native types work exactly as for ISO C++
compilation without /clr but attempting to use concepts with C++/CLI
types generates a diagnostic. It is possible to widen concepts to allow
a carefully chosen subset of the C++/CLI type universe, but for this
version of MSVC, we have chosen to keep them separate. Removing the line
with the diagnostic and inspecting the disassembly shows us

IL_0009:  ldloca.s   V_3
IL_000b:  ldloca.s   V_2
IL_000d:  call       void
modopt([mscorlib]System.Runtime.CompilerServices.CallConvCdecl)
  'Swap'(
    valuetype SwapMe* modopt([mscorlib]System.Runtime.CompilerServices.IsImplicitlyDereferenced),
    valuetype SwapMe* modopt([mscorlib]System.Runtime.CompilerServices.IsImplicitlyDereferenced))

Note that the parameter types of the function are SwapMe* and the
concept std::swappable does not appear.

Modules

As mentioned above, in C++/CLI modules can only be imported, either as
regular ISO C++ modules, or header units, created from headers that
contain no C++/CLI code. Thus, we have these restrictions on modules:

module m;               // error under /clr
export module m;        // error under /clr
export class X;
export import m;        // error under /clr
import m;               // OK with /clr
import ;        // header units OK with /clr

From the command-line, certain flag combinations will produce errors:

cl /exportHeader /clr ...       # error
cl /ifcOutput /clr ...          # error
cl /ifcOnly /clr ...            # error

Interop and module import

Since, currently we don’t allow module export under /clr, and since
the modules can have code in associated .obj files, unless built with
/ifcOnly, it follows that a call to any imported non-inline function
has to be an interop call to native code. For templates, this
restriction is not required and hence importing, say the class template
std::vector, can result in its member functions being compiled to
managed code. This is an important consideration for performance since
interop calls will inhibit inlining. We shall provide more guidance in a
future blog article, when support for modules under /clr ships.

Conclusion and call to action

C++20 support is being added to C++/CLI with very few restrictions as
far as native types are concerned. The general principle followed is
that of least surprise: if a particular feature is valid in a native
compilation, there is a high chance it is also valid under /clr.

If you have C++/CLI code, we encourage you to turn on C++20 compilation,
try the product and report bugs via Visual Studio Feedback. If you have
specific need for modules to be used in conjunction with C++/CLI, again,
we would appreciate feedback.

Tanveer Gani
Principal Software Design Engineer, Microsoft Visual C++