Reflection landed in C++26 last year, GCC trunk and the Bloomberg-maintained Clang fork already implement most of it. Many conference talks is making it sound like it’s the most important thing to happen to the language in a generation. If you ship production C++ on MSVC, the more useful question is what reflection actually changes about the code you write, and when you’ll be able to write any of it on your stack.
Here’s a short read on what’s worth your attention now, where you may want to filter the noise, and what to do about it on a stack that doesn’t have it yet.
What reflection actually is, in 90 seconds
Here’s the smallest example we can show, using the P2996R13 syntax that was voted into the standard:
struct Point { int x; int y; };
constexpr auto members = std::meta::nonstatic_data_members_of(^^Point);
// members[0] is a "reflection" of Point::x
// members[1] is a "reflection" of Point::yThe new ^^ operator yields a reflection — a first-class value at compile time that represents some piece of your program. From there, dozens of new compile-time queries (nonstatic_data_members_of, enumerators_of, identifier_of, and so on) let you ask the compiler about your types, and a corresponding splice syntax ([: ... :]) lets you generate code from the answers. Both halves matter. Introspection without reification is just a fancy typeid.
It’s static reflection. Everything happens at compile time to avoid runtime cost and stuff like RTTI overhead. And it’s part of the language now, not a third-party preprocessor or build-time codegen step glued to your project.
In plain English: until now, when you wanted to do something like “for every field in this struct, generate code that does X,” you had to use macros, write a code generator, or pull in a heavy template library. Reflection lets the compiler do it natively. You ask the compiler about your types, and you can use the answers to generate code in the same file.
Quick refresher: Why does C++ need reflection
C++ reflection solves a long-standing limitation: C++ types don’t naturally expose their own structure. If you want to inspect fields, serialize data, or generate tools, you usually have to duplicate that information manually. Large systems like Unreal Engine work around this by building custom reflection layers using macros and external code-generation tools—effectively simulating a feature the language never had.
Modern C++ reflection aims to eliminate that complexity by letting the compiler expose type information directly at compile time. This makes it possible to automatically generate serialization, debugging, and editor tooling without macros or duplicate code—all while keeping C++’s zero-runtime-overhead performance model.
The four things this actually unlocks
Enum-to-string, finally
The most-requested missing feature in C++ for two decades is suddenly a one-liner. You’ll see this example in every reflection talk for the next three years. There’s a reason for that: it’s the example that makes everyone in the room go “finally…”.
template <typename E>
constexpr std::string_view enum_to_string(E value) {
std::string_view result = "<unknown>";
[: expand(std::meta::enumerators_of(^^E)) :] >> [&]<auto e>{
if (value == [:e:]) result = std::meta::identifier_of(e);
};
return result;
}No external code generator. No X-macro tricks. No magic_enum (much love, but it’s a workaround for a missing feature, and it’s bounded by template recursion limits). It’s just included in the language.
Serialization without the boilerplate
Every serialization library you’ve used has the same shape. It asks you to describe your types twice, once in C++ and once in some macro or trait specialization that tells the library how to walk them. With reflection, the library walks them itself.
template <typename T>
std::string to_json(const T& obj) {
std::string out = "{";
[: expand(std::meta::nonstatic_data_members_of(^^T)) :] >> [&]<auto m>{
out += std::format("\"{}\":{},",
std::meta::identifier_of(m),
to_json(obj.[:m:]));
};
out.back() = '}';
return out;
}This significantly generalizes multiple formats in a handy process. JSON, YAML, protobuf, command-line parsers, ORM mappings, RPC stubs — anything that’s “the shape of my data, but in another format” collapses from “two places to update” to one. Rename a field, the mapping moves with it—that’s a class’s worth of bugs that disappears immediately.
Mocking, DI, ORMs, and other “shape-driven” libraries
The same pattern unlocks mocking frameworks that don’t need MOCK_METHOD macros, dependency-injection containers that wire themselves up from a class definition, and ORM mappers that follow your struct around when you rename a field. None of these libraries exist on P2996 yet — the standard is too fresh — but the building blocks are now in the language, which means the libraries are coming (hopefully). The first wave will set the patterns everyone copies for the next decade.
Want to try the examples? All three snippets should compile on Compiler Explorer using the x86-64 clang (experimental P2998) compiler from the dropdown.
Where the hype is ahead of reality
A few caveats are worth keeping in mind, since the conference talks tend to skip them. Compile-time impact is the biggest open question — reflection runs at compile time and isn’t free, but production benchmarks are still thin on the ground. Tooling lag is the quieter one: compilers will accept reflection-based code months before debuggers, formatters, and IDE navigation fully catch up. And not everything in the original proposal made the cut. P3687 deferred splice template arguments to C++29 because the wording and implementation weren’t considered ready. C++26 reflection is real and it’s significant, but it isn’t the full surface area you might have read about in earlier write-ups.
What about Visual Studio?
This is the section the MSVC reader is here for, so let’s just say it.
As of late April 2026, MSVC has no public reflection support and no published ETA. The C++ Team Blog post for Visual Studio 2026 v18.0 — which ships with MSVC build tools 14.50 — does not mention reflection. The features it does highlight are C++23 conformance items, suggesting Microsoft is still finishing the previous standard before C++26 features land in earnest. The Developer Community thread requesting C++26 features has Microsoft engagement but no committed timeline for reflection specifically.
So if you ship on MSVC: you can read about reflection, prototype it on Compiler Explorer to get a feel for the ergonomics, and audit your codebase for the patterns reflection will eventually simplify. But you can’t ship with it on stock Visual Studio yet. Based on Microsoft’s historical cadence with major C++ features (concepts, modules, and coroutines all took multiple VS releases to mature), a realistic adoption window is probably 12–24 months from the day MSVC first ships an experimental implementation. That’s an estimate, not a Microsoft commitment.
There’s a useful way to think about this. Reflection is the language eventually catching up to something developers have always done with tooling: asking the codebase about itself. Where is this symbol used? What’s the shape of this type? If I rename this, what breaks? These are reflection-shaped questions, and they have answers today. They just live in your IDE instead of your source code.
Until reflection lands in MSVC, the day-to-day version of “ask your codebase about itself” still happens through your IDE — finding references, jumping to definitions, renaming a symbol everywhere it’s used. If that workflow holds up on your codebase, you’re set. If it doesn’t, especially on large projects, heavy macros, or legacy C++ where stock IntelliSense slows down, Visual Assist is what we build for that case.
Should you care right now?
It depends on what you ship.
If you’re shipping production C++ on MSVC, read the spec and don’t bet on reflection landing in your workflow this year. Don’t refactor anything in anticipation. The horizon is too far out and the design might still shift in small ways.
If you maintain libraries that other people depend on — serialization, ORM, RPC, DI containers — start sketching the reflection-based API now. The first wave of libraries that ship clean reflection-based interfaces will set the patterns everyone else copies for years.
If you’re on GCC or Clang and you’ve been wanting to delete a code generator from your build, prototype this month. The Bloomberg fork runs in Compiler Explorer. Pick the smallest codegen step in your build and try replacing it.
And if you’re in a meeting where someone says C++26 reflection is going to change everything, they’re right and they’re wrong. It closes a gap that has existed since C++ existed. The language can finally see itself, and that will reshape how libraries get built. But not this year, not on MSVC, and probably not in the way the loudest take on Hacker News predicts. The boring uses are the ones that will matter most.
If you’re using reflection in production already, or you have firm benchmarks on the compile-time cost, drop us a note. We’d genuinely like to hear what you’re seeing.
30-day free trial · All features unlocked