Frequently, whenever the topic of Reflection comes up, I see a lot of complains specifically about the new syntax being added to support Reflection in C++26. I’ve always thought of that as being largely driven by unfamiliarity — this syntax is new, unfamiliar, and thus bad. I thought I’d take a different tactic in this post: let’s take a problem that can only be solved with Reflection and compare what the solution would look like between:

Dan Brevik's blog covers a broad range of topics, including web development, programming languages, and software engineering best practices. Readers can find tutorials on front-end frameworks, back-end technologies, and principles for writing clean, maintainable code in various programming languages. Additionally, they can explore articles on software architecture, design patterns, and strategies for improving developer productivity and collaboration.

Barry's C++ Blog

Compares C++26's value-based reflection model with the older Reflection Technical Specification's type-based approach by implementing a structural type trait. The value-based model uses new syntax (^^E and [: r :]) but results in simpler, more readable code that resembles regular programming rather than complex template metaprogramming. The author demonstrates how value-based reflection eliminates the need for extensive template machinery and allows for both functional and imperative programming styles.

Type-based vs Value-based Reflection