It’s the capability of a program to “reflect” upon itself, I.E. to inspect and understand its own code.

As an example, In C# you can write a class…

public class MyClass
{
    public void MyMethod()
    {
        ...
    }
}

…and you can create an instance of it, and use it, like this…

var myClass = new MyClass();
myClass.MyMethod();

Simple enough, nothing we haven’t all seen before.

But you can do the same thing with reflection, as such…

var type = System.Reflection.Assembly.GetExecutingAssembly()
    .GetType("MyClass");

var constructor = type.GetConstructor(Array.Empty<Type>());

var instance = constructor.Invoke(Array.Empty<Object>());

var method = type.GetMethod("MyMethod");

var delegate = method.CreateDelegate(typeof(Action), instance);

delegate.DynamicInvoke(Array.Empty<object>());

Obnoxious and verbose and tossing basically all type safety out the window, but it does enable some pretty crazy interesting things. Like self-discovery and dynamic loading of plugins, or self-configuration of apps. Also often useful when messing with generics. I could dig up some practical use-cases, if you’re curious.

Not a C++ dev, but looking at Java, which has reflection: Reflection allows to inspect and modify runtime attributes of classes, interfaces, fields and methods. Even, when you don’t know their names at compile time.

Basically take any object and just ask “what are your (even private) fields?” and then happily modify them, or call these methods, or…

There’s a pretty big difference though. To my understanding enable_if happens at compile time, while reflection typically happens at runtime. Using the latter would cause a pretty big performance impact over a (large) list of data.

You already can do that with C++20 concepts and the requires expression

template <typename T>
concept has_member_foo = requires(T t) {
    t.foo();
};

// Will fail to instantiate (with nice error 
// message) if t.foo() is ill-formed
template <has_member_foo T>
void bar(T t) {
    // ...
}

// abbreviated form of above
void baz(has_member_foo auto t) {
    // ...
}

// verbose form of above
template <typename T> requires
    has_member_foo<T>
void biz(T t) {
    // ...
}

// same as above but with anonymous concept
template <typename T> requires
    requires(T t) { t.foo(); }
void bom(T t) {
    // ...
}

// If already inside a function
if constexpr (has_member_foo<T>) {
    // ...
}

// Same but with anonymous concept
if constexpr (requires(T t) { t.foo(); }) {
    // ...
}

This, however, is about diagnostics, i. e. annotating delete with a reason (message) to express developer intent when deleting a function, not about memory management.

Garbage collection was at some point part of the spec but was removed in 23.

https://en.cppreference.com/w/cpp/memory/gc/declare_reachable

There’s C++/CLI if you want to combine garbage collection with the pain of C++

See my other comment for more detials but it kind of destroys the type safety of the language. In Java for example, it lets you modify private/protected fields and call private/protected methods.

It’s also slower than accessing a field normally since you need to do a string lookup (but slightly faster than a hashmap/dictionary) so if you use it over a large enough list it’ll cause slowdowns.

Most use cases for it in Java/C# revolve around testing, serialization, and dynamic filtering/sorting. And most of those cases can be handled more safely using macros/attributes because that gets handled at compile-time in C/C++.