Looking at the examples (https://isocpp.org/files/papers/P2996R4.html#examples) what really stands out is the direct integration of type-syntax into the language. It fits in with a certain token-substitution way that connects back to templates. It also replaces some of the uglier operators (typeof?).

I hope it goes int! During the language's stagnation I left for a while, perhaps it'll be competitive again soon.

So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

I think the committee is focused on the wrong things

Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.

False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.

(for context: parent is referring to the fact that x64 calling conventions mandate structs larger than 64 bits to be passed in memory, which means that passing a 128bit std::span is going to be less efficient than passing a separate 64bit index and 64bit length, as those can go into registers)

Other ABIs might have different constraints but there is no reason why they couldn't special case std::span. In fact if span was a built-in type there is nothing preventing a compiler form picking a suboptimal ABI and being stuck with it. In any case it is not a standardization issue, but purely a QoI.

>Structs and unions of size 8, 16, 32, or 64 bits, and __m64 types, are passed as if they were integers of the same size. Structs or unions of other sizes are passed as a pointer to memory allocated by the caller.

https://learn.microsoft.com/en-us/cpp/build/x64-calling-conv...

> In any case it is not a standardization issue, but purely a QoI.

This is an enormous problem in the C++ ecosystem - playing hot-potato with whose fault it is, instead of trying to actually fix it. Span is a decent example, the standards committee get to say it's a vendor issue, and the vendors get to say that their hands are tied by the ABI. The result is that people spend time arguing about who should fix it rather than actually fixing it.

In any case this has nothing to do with std::span being an technically a library type or a built in. There is really no fundamental difference between the two.

For example std::complex and std::initializer_list have special handling on many compilers, just to mention two types.

Start with having the standards committee accept that they are in fact where the buck stops, and that the language includes, whether they like it or not, the toolchain. They don't have to decide upon the toolchain, but their current MO of "toolchain/ABI issue == not our problem (except for when we decide we're not willing to make any backwards incompatible ABI changes, but only sometimes)." The vendors are already jumping through hoops to support what is being standardised (modules being the perfect example here).

I can't speak for std.complex as I've never had to use it, but I think initializer list would be a great example of "how much better would this be if it was special cased into the compiler". The benefit we would get from initialisation being consistent with the compiler far outweighs the benefit of being able to use libc++'s initialiser list with clang.

> There is really no fundamental difference between the two.

Except there is. If I write an implementation of the standard library, and provide an implementation of std span as (abbreviated) - https://gcc.godbolt.org/z/c1sz4neKG it's got to respect the various conventions instead of being treated as an opaque type (like a slice in go). If it's a `_Span`, the compiler is free to go "ok you're using this thing that I know all the internals of, and can reason about. I can elide bounds checks that don't pass muster, I can specify that I will generate code for this specific type that puts extent and data as registers in the following cases". But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory.

Now, you might call that a QOI issue, but I'd call it a design flaw that could have avoided an implementation issue, that we see on many features.

That's not an exception. The committee is not willing because the implementors explicitly said it is not going to happen, no matter how much Google cries.

> Except there is. If I write an implementation of the standard library, and provide an implementation of std span

if you write it as an user you are constrained by the ABI. But implementors are not: they can bless their own span with superpowers if they want to (in practice they would use special attributes). And there is no reason the compiler can't have builtin knowledge of the semantics of std::span (the same way it has knowledge of printf, malloc and the various math functions for example).

> But instead, on x64 (where I work 99% of the time so it's where my effort/knowledge is, sorry), we're bound by >64 == memory.

[Note this is an MSVC-specific ABI issue not a general x64 one. GCC uses the Itanium ABI on x64]

But the MSVC issue is really a red herring: there is a-priori no reason to expect they would have picked a better ABI for a built-in _Span. The committee cannot force compilers to be optimal (it can't even force conformance).

(Note I'm not singling out MSVC, GCC also has multiple less than ideal ABI decisions).

Yeah, and I think this is the problem at the root of my gripe. If the committee was willing to reach this point earlier I think we’d be better off!

> But implementors are not: they can bless their own span with superpowers if they want to

Except that they don’t. And we can go around in circles here - I maintain this is a design issue, and it should be fixed at the design stage, rather than passed on to the compiler vendor who are stuck behind the theoretical design that pretends an ABI doesn’t exist, and their customers who will not upgrade if they break the ABI.

Lastly, I agree that the committee cannot force conformance or optimality, nor should they. But their unwillingness to accept that unless it’s technically impossible, the vendors will move mountains for conformance. This leaves us fighting with each other over who is to blame (see this thread), and in my opinion the end result is a half baked outcome that solves the paper problem but doesn’t solve the actual users wants.

Except they do. Look at GCC code for std::complex compared to the equivalent hand rolled class: https://gcc.godbolt.org/z/nqcvhPWex . edit: note that in this case GCC is just silly with the hand rolled one, but it does show that they are treated differently.

GCC does similar things with span where the class has special annotations for reference tracking to improve warning messages.

Library vs builtin is an implementation issue, not a standardization one. But yes, we are going in circle.

In fact the truth is the people working on C++ don't actually value fast compile times over other matters (fast runtime, ABI compatibility, etc.)

They say they do. But they don't in their actions.

One egregious example: look at the compilation speeds of clang with release build configs (-O2 or higher, etc.) over the years.

It compiles much slower now than it did in 2014 for the same code. The compilation speed is worsening at a much faster rate than the runtime speeds are improving from version to version.

This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to be standardized (or indifinitely - not everything should be added to the stdlib). But even language features can and should exist as compiler extensions before we are stuck with them.

One nice advantage of static reflection, macros and other form of program synthesis is that you can experiment with new syntax as a library before committing to integrating it to the base language.

Care to point an example?

- export templates is the canonical one.

- Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal.

- Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun.

- Coroutines are overly complex and still incomplete but I still have hope.

- Modules feel DOA so far.

- Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property.

edit: overall I'm happy with the evolution of the language, but the standardization process has flaws

Which is what I have been using on my C++ hobby projects for the last two years, on work projects we are still on C++17 land anyway.

Published in 1994.

Literally 30 years ago, years before there was even anything resembling a C++ standard.

I'm not sure why you thought it's relevant.

however, even if we only consider the 01994 version, i still extensively disagree with your comment, and i will explain why in detail

in fact c++ was already well defined before ansi formed their committee in 01990, four years before the version of that faq that you chose to read. the arm (not the arm arm, the annotated reference manual) was the standard standard until c++98, and it's written as one. it says things like

> The following rule limits the context sensitivity of the rewrite rules for inline functions and for class member declarations in general. A class-name or a typedef-name or the name of the constant used in a type name may not be redefined in a class declaration after being used in the class declaration, nor may a name that is not a class-name or a typedef-name be redefined to a class-name or a typedef-name in a class declaration after being used in the class declaration. For example,

(that's from §9.9 if you want context)

but why would it be relevant whether there was a c++ standard or not? it would be relevant if the problems documented in the 01994 version of the faq-lite had been eliminated by standardization. but that is comprehensively not the case. every single one of the misconceived features in the 01994 version of the faq-lite is still in everything resembling a c++ standard, so all the pitfalls of poorly interacting features it documents are still relevant today. that's why i think that even the 01994 version of the faq-lite is relevant

so from my point of view it is not only wholly false to say that there was nothing resembling a c++ standard in 01994, it is also irrelevant whether there was anything resembling a c++ standard when the faq-lite was written (at least for 01994 and later versions)

furthermore, your particular choice of 01994 is unjustifiable and evidently only serves to provide a spurious veneer of justification for your irrelevant objection that (interpreting you generously) the faq-lite predates the c++98 standard. if you thought that was important you should have picked a version of the faq-lite from 01999 to criticize

______

† after a hiatus, since 02019, it is again being updated at https://www.parashift.com/c++-faq-lite/ but obviously the new center of gravity for this kind of thing is stack overflow and cppreference

Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the experience of anyone maintaining C++ projects.

That's perfectly fine. You should only pay for what you use.

Your average project, however, consumes dependencies and needs to keep them updated. Just because the code you write doesn't use them that doesn't mean your dependencies don't. So everyone still benefits with each release of C++ even if the are not using fancy features.

I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/tools people.

No, you can't. Not in the long run, at least. You will have to use libraries that have chosen a different subset, new people will join your team, things will get sloppy as the company grows, etc. Committing to a subset of the language is not free, it's hard and it's a lot of work. And for what?

That is harder than it sounds. First you have to select which subset to use, it is almost impossible to get any two engineers to agree on that - if you do get agreement that is a bad sign - generally it means the people in the room don't know C++ well enough to make the decision and so you choose the wrong one. The best you can hope for is a compromise where nobody is happy - and thus everyone will look for an excuse to bring in their pet part of C++ not in the subset because there is a "good reason" for an exception.

Even if you select a subset it is almost impossible to enforce whatever subset because even if you don't allow your people to use it directly odds are you bring in a third party library that does use it (the C++ standard library being the big one!)

There are a few exceptions to the above. No exceptions/no RTTI are commonly disabled exceptions and so you will get some compiler and library support. Game companies commonly write their own standard library. Both of these are done for performance reasons and have specific domain specific reasons that can be validated in a profiler to set their rules.

Not related to reflection, but C++26 is also likely to get profiles which will disable specific old constructs, (new/delete) which are proven to be error prone and thus result in security issues. These are a good subset to use, but it is about security and so mostly doesn't get the types of subsets you are talking about.

Plenty of the modern C++ people already do this by enforcing things like "no raw loops", "no raw pointers", or "no raw synchronization primitives" during code review.

The issue is that it's a lot harder to justify avoiding new features than it is to justify avoiding old features unless you have a tooling specific reason (ex lack of support) to do so.

There is the problem - code reviews are done by humans and so it is really easy to read some code and not think "wait this is new code it can't do that anymore". I read a lot of old code as part of my job and it often isn't worth the bother to update working code to new standards.

> it's a lot harder to justify avoiding new features than it is to justify avoiding old features

The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.

I think we are saying the same thing here. Often the new is better so it's hard to really justify sticking to the old outside of project specific reasons (i.e. toolchain doesn't support new std). That people do it has less to do with justification and more to do with time commitment or laziness and the excuses given tend to fall away once pressed.

However that opinion is kind of a minority. There are a lot of people in the community who don't want to have to learn new features just because a dependency happens to use/expose them. I don't personally see the issue with it.

I'd rather learn std features any day over non-std features. It's just a better use of my time because they work everywhere and someday I might need them. However again not everyone shares this opinion.

If you're writing library code that someone else might use, you don't have much need to understand the features you don't use, unless you have to handle them at the interface. If you're debugging your own code, you really shouldn't have to understand features that you didn't use. (Mostly - see the next paragraph.)

You did say "intentionally". You could wind up using a feature unintentionally, but it's not very common, because most of the new features are either in a new library (which you have to explicitly call), or a new syntax. There are definitely exceptions - I could easily see you using a move constructor without meaning to.

Maintaining someone else's code... yeah. You have to understand whatever they used, whether or not it made any sense for them to use.

And that clang likely just didn't have full c++20 support. Which tbf I actually don't think any clang has full c++20 support currently as even bleeding edge clang still is missing a few things in the lang and library departments.

Since the proposals target problems with differing philosophies, they each have different traps in them from bad time complexity to outright unrefined behavior. Keeping up with the updates hard because of this.

I think many C++ projects are (or will be) basically infeasible to maintain not because of the old problems but due to the exploding complexity of the interactions of all features, unless developers actively ban using large parts of the language.

I don't really see this as true. In my experience most C++ features actually "just work" together and there are relatively few footguns involved in mixing features.

And it's less that C++ is a patchwork language and more that it is multi-paradigm and multi-discipline. Some features have specific applications and they get used inappropriately but in my experience that is solved with a quick reference/citation of the standard during code review or in a new ticket.

1. how immense the language has become, and how hard it got to learn and implement

2. how "modernising" C++ gives developers less incentives to convince management to switch to safer languages

While I like C++ and how crazy powerful it is, I also must admit decades of using it that teaching it to new developers has become immensely hard in the last few years, and the "easier" inevitably ends up being the unsafe one (what else can you do when the language itself tells you to refrain from using `new`?).

Tree algorithms that are simple in literature get bloated and slow with shared_ptr.

The only issue with pointers in C++, which C does not have, is that so many things are copied around by default if one is using classes. So the way to deal with tree algorithms is to have a hidden tree with pointers and a class that wraps the tree and deletes all dangerous copy methods, implicit and explicit.

stdlib++ seems to use that approach as well.

If you add an iterator, the iterator needs internal pointers to the nodes, so by definition the node pointers are not unique. Again, raw pointers are better.

I have never seen a complex data structure where unique_ptr is really used.

> I have never seen a complex data structure where unique_ptr is really used.

What's a "complex" data structure? Anyway, I'd expect to see unique_ptr more in user code rather than in library implementations of data structures where where relatively minor concerns might warrant an ad-hoc implementation even if you could use unique_ptr. In many cases it's probably just that the implementations precede the standardized smart pointers.

It is just a different syntax for the same thing.

I honestly think people just find the words “unique ptr” scary or syntactically overwhelming. If that is true, fortunately we also have using aliases :)

But also, pointing out problems doesn’t mean that something is useless. Something can be a net good, yet still have downsides.

There are all sorts of issues with pointers (and not just in C++) - which are inherent to their use. They can point anywhere! They're mutable! They can be null! It's difficult/impossible to ensure they hold a valid value!

Common wisdom is to avoid excessive use of pointers when you don't _really_ need - even smart pointers.

Consider this fine presentation for example:

"Don't use fking pointers" https://klmr.me/slides/modern-cpp/#1

Use references, especially as function parameters,

* Returning values in modern C++ typically does _not_ involve any copying.

* If you want to indicate the possibility that your value is uninitialized/invalid - use std::optional<T>, which can hold either an actual T value or an std::nullopt (being in an "empty" or "value-less" state).

* If your data is in some buffer (or span, or vector etc.), you can use offsets into that buffer.

* Many uses of pointers are due to the "need" to utilize polymorphism: myobj->foo() . Well, typically, you know the real type at compile-time, and can write a freestanding foo() function, which is polymorphic via overloading, or being templated over its parameter's type.

* And speaking of virtual methods and class hierarchies, you can often make do with a template parameter instead of a choice of subclass; or with an std::variant<Foo, Bar>

As I wrote, the stdlib++ agrees. Read that code and reevaluate your view on whether it is ridiculous.

For other graphs, it depends on the specific application. I am not saying that shared_ptr is always wrong, but often it is.

Even Go is rediscovering that staying simple just doesn't happen for any language that gets industry adoption at scale.

If you read the new "compilers" [1] in packages like PyTorch, which are unfortunately written in Python, you stare at a huge code base with walls of text, objects calling one another in a maze of ravioli code and generally no help at all to make sense of it all.

Compare that to the gcc code bases, where it is always possible to find some entry point to understand the whole thing.

[1] "compilers", because despite the huge code base (wasn't Python supposed to be terse?) they preprocess the function graph and then call g++ and Triton to do the actual work.

Indeed I wish they were even more aggressive about breaking changes

Rust is nifty but there is simply too much existing C/C++ out there and "rewrite it in Rust" is not a serious suggestion

Maybe one day we have some cool AI that magically rewrites old C/C++ automatically, but by then I also assume we will have AI-designed languages

Until then, we need C/C++ to be maintained and modernized because we are actually running the world with these languages

I bring it up partially because they are not taking a "rewrite it in Zig" approach, they are specifically aiming for incremental migration in mixed C / Zig codebases.

More specifically, with this I can iterate over struct members and get their names and types, but I cannot attach additional information to these members, like whether they should be serialized or under which name.

The referenced proposal P1887R1 covers this, but that's not included here, right?

P1887R1: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p18...

  * What type of problems static reflection could solve, in general?
  * Are there specific cases and / or situations where static reflection could resolve such case, even simplify an unnecessary complexity?

* Converting enum values to strings, and vice versa

* Parsing command line arguments from a struct definition (like Rust's clap)

* Simple definition of tuple and variant types, without the complex metaprogramming tricks currently used

* Automatic conversion between struct-of-arrays and array-of-structs form

* A "universal formatter" that can print any struct with all its fields

* Hashing a struct by iterating over its fields

* Convert between a struct and tuple, tuple concatenation, named tuples

    enum class Color { Red, Green, Blue };

    template<typename E>
    std::string enum_to_string(E value) {
        constexpr auto enum_info = reflect(E);
        for (const auto& enumerator : enum_info.enumerators()) {
            if (enumerator.value() == value) {
                return std::string(enumerator.name());
            }
        }
        return "Unknown";
    }

    template<typename E>
    E string_to_enum(const std::string& str) {
        constexpr auto enum_info = reflect(E);
        for (const auto& enumerator : enum_info.enumerators()) {
            if (enumerator.name() == str) {
                return enumerator.value();
            }
        }
        throw std::invalid_argument("Invalid enum string");
    }

    struct CLIOptions {
        std::string input_file;
        int num_threads = 1;
        bool verbose = false;
    };

    template<typename T>
    T parse_cli_args(int argc, char* argv[]) {
        T options;
        constexpr auto struct_info = reflect(T);

        for (int i = 1; i < argc; i++) {
            std::string arg = argv[i];
            for (const auto& member : struct_info.members()) {
                if (arg == "--" + std::string(member.name())) {
                    if (member.type() == typeid(bool)) {
                        member.set(options, true);
                    } else if (i + 1 < argc) {
                        member.set(options, std::string(argv[++i]));
                    }
                    break;
                }
            }
        }
        return options;
    }

    

    // Common data structure used in examples below

    struct Person {
        std::string name;
        int age;
        double height;
    };

    // Tuple, without reflection

    int main() {
        std::tuple<std::string, int, double> person_tuple{"John Doe", 30, 175.5};

        std::cout << "Name: " << std::get<0>(person_tuple) << std::endl;
        std::cout << "Age: " << std::get<1>(person_tuple) << std::endl;
        std::cout << "Height: " << std::get<2>(person_tuple) << std::endl;

        Person p{"Jane Doe", 25, 165.0};
        auto p_tuple = std::make_tuple(p.name, p.age, p.height);

        return 0;
    }

    // Tuple, with reflection

    int main() {
        std::tuple<std::string, int, double> person_tuple{"John Doe", 30, 175.5};

        std::apply([](const auto&... args) {
            (..., (std::cout << reflect(args).name() << ": " << args << std::endl));
        }, person_tuple);

        Person p{"Jane Doe", 25, 165.0};
        auto p_tuple = std::apply([&p](auto... members) {
            return std::make_tuple(members.get(p)...);
        }, reflect(Person).members());

        return 0;
    }

    // Variant, without reflection

    int main() {
        std::variant<int, std::string, Person> var;

        var = 42;
        std::cout << "Variant holds: " << std::get<int>(var) << std::endl;

        var = "Hello, World!";
        std::cout << "Variant holds: " << std::get<std::string>(var) << std::endl;

        var = Person{"Alice", 28, 170.0};
        const auto& p = std::get<Person>(var);
        std::cout << "Variant holds Person: " << p.name << ", " << p.age << ", " << p.height << std::endl;

        std::visit([](const auto& v) {
            using T = std::decay_t<decltype(v)>;
            if constexpr (std::is_same_v<T, int>)
                std::cout << "Int: " << v << std::endl;
            else if constexpr (std::is_same_v<T, std::string>)
                std::cout << "String: " << v << std::endl;
            else if constexpr (std::is_same_v<T, Person>)
                std::cout << "Person: " << v.name << std::endl;
        }, var);

        return 0;
    }

    // Variant, with reflection

    int main() {
        std::variant<int, std::string, Person> var;

        var = 42;
        std::cout << "Variant holds: " << std::get<int>(var) << std::endl;

        var = "Hello, World!";
        std::cout << "Variant holds: " << std::get<std::string>(var) << std::endl;

        var = Person{"Alice", 28, 170.0};
        
        std::visit([](const auto& v) {
            constexpr auto type_info = reflect(std::decay_t<decltype(v)>);
            std::cout << "Variant holds " << type_info.name() << ": ";
            if constexpr (type_info.is_class()) {
                for (const auto& member : type_info.members()) {
                    std::cout << member.name() << ": " << member.get(v) << ", ";
                }
            } else {
                std::cout << v;
            }
            std::cout << std::endl;
        }, var);

        return 0;
    }

    template<typename Struct, size_t N>
    auto soa_to_aos(const StructOfArrays<Struct, N>& soa) {
        std::array<Struct, N> aos;
        constexpr auto struct_info = reflect(Struct);

        for (size_t i = 0; i < N; ++i) {
            for (const auto& member : struct_info.members()) {
                member.set(aos[i], soa.get(member.name())[i]);
            }
        }
        return aos;
    }

    template<typename Struct, size_t N>
    auto aos_to_soa(const std::array<Struct, N>& aos) {
        StructOfArrays<Struct, N> soa;
        constexpr auto struct_info = reflect(Struct);

        for (size_t i = 0; i < N; ++i) {
            for (const auto& member : struct_info.members()) {
                soa.get(member.name())[i] = member.get(aos[i]);
            }
        }
        return soa;
    }

    template<typename T>
    std::string format(const T& obj) {
        std::ostringstream oss;
        constexpr auto type_info = reflect(T);

        oss << type_info.name() << " {\n";
        for (const auto& member : type_info.members()) {
            oss << "  " << member.name() << ": " << member.get(obj) << ",\n";
        }
        oss << "}";
        return oss.str();
    }

    template<typename T>
    size_t hash_struct(const T& obj) {
        size_t hash = 0;
        constexpr auto type_info = reflect(T);

        for (const auto& member : type_info.members()) {
            hash ^= std::hash<decltype(member.get(obj))>{}(member.get(obj)) + 0x9e3779b9 + (hash << 6) + (hash >> 2);
        }
        return hash;
    }

    // Struct to tuple
    template<typename Struct>
    auto struct_to_tuple(const Struct& s) {
        return std::apply([&](auto&&... members) {
            return std::make_tuple(members.get(s)...);
        }, reflect(Struct).members());
    }

    // Tuple to struct
    template<typename Struct, typename Tuple>
    Struct tuple_to_struct(const Tuple& t) {
        Struct s;
        std::apply([&](auto&&... members) {
            ((members.set(s, std::get<members.index()>(t))), ...);
        }, reflect(Struct).members());
        return s;
    }

    // Tuple concatenation
    template<typename... Tuples>
    auto tuple_concat(Tuples&&... tuples) {
        return std::tuple_cat(std::forward<Tuples>(tuples)...);
    }

    // Named tuple
    template<typename... Members>
    struct NamedTuple {
        REFLECT_NAMED_MEMBERS(Members...);
    };

Addressing real problems with simple solutions isn't allowed.

The for loop required to do enum to string really makes it

I suppose I just yearn for an all-in-one build system + package manager like exists in Rust or Go. Once you've seen what can be possible when these things are integrated from the ground up it sort of ruins your C++ build experience!

>Reflection needs support from the compiler. Just add new syntax and put it on the compiler, ffs!

Converting enums to strings is one use case for reflection. Do you suggest introducing bespoke syntax for the other use cases too?

My gripe, if you will, is that converting an enum value to a string is a basic feature (as in, not reducible to other features) of every language that supports doing that. Not everything should be part compiler part library. And it doesn't need to be bespoke syntax. Enum values are already objects from the point of view of the compiler. Just give them a str member. This is similar to how in Rust built-in integers also have members. It's not bespoke, it's using already-existing syntax for objects and extrapolating it to other types. Another alternative that wouldn't involve bespoke syntax would be giving enum values an operator const char *() overload, either explicit or implicit.

>Converting enums to strings is one use case for reflection. Do you suggest introducing bespoke syntax for the other use cases too?

The other cases are pretty much all variations of enumerating members of a class. I have no problem with those examples, since it's basically how it's done everywhere. You get a meta object for the type that a function that enumerates the members of the type, and you go through it.

Because other than the free function vs member access thing, I don't see why it would concern the user of `enum_to_string()` that it's a proper function instead of a keyword like `static_assert`...

Does static reflection simplify such cases? ... Outlook unclear. It's definitely gnarlier to actually write the serialize() method, and in many cases, it does feel like a better option is to write a specific domain-specific language to specify what you want to specify, with a tool to operate on it as appropriate (think something like protobufs for serialization).

Same for command line parameters. We want documentation strings, maybe dashes in the name etc.

But that can surely be solved with a little more advanced struct

Implementing serialization for complex types often requires manual code writing or external tools. With static reflection you could automate this process

  template<typename T>
  void serialize(const T& obj, std::ostream& os) {
      for_each(reflect(T), [&](auto member) {
          os << member.name() << ": " << member.get(obj) << "\n";
      });
  }

    class Person {
    public:
        Person(const std::string& name, int age)
            : name(name), age(age) {}

        std::string getName() const { return name; }
        void setName(const std::string& name) { this->name = name; }

        int getAge() const { return age; }
        void setAge(int age) { this->age = age; }

    private:
        std::string name;
        int age;

        REFLECT_PROPERTIES(
            (name, "Name of the person"),
            (age, "Age of the person")
        )
    };

    int main() {
        Person person("Alice", 30);

        auto properties = reflect::getProperties<Person>();

        for (const auto& prop : properties) {
            std::cout << "Property: " << prop.name 
                    << " (" << prop.description << ")" << std::endl;
            
            auto value = reflect::get(person, prop.name);
            std::cout << "Value: " << value << std::endl;

            if (prop.name == "age") {
                reflect::set(person, prop.name, 31);
            }
        }

        std::cout << "Updated age: " << person.getAge() << std::endl;

        return 0;
    }

    template<typename T>
    void printTypeInfo() {
        constexpr auto info = reflect(T);
        std::cout << "Type name: " << info.name() << "\n";
        std::cout << "Member count: " << info.members().size() << "\n";
    }

    template<typename T>
    void printAllMembers(const T& obj) {
        for_each(reflect(T), [&](auto member) {
            std::cout << member.name() << ": " << member.get(obj) << "\n";
        });
    }

Serialization

    #include <print>

    template<typename T>
    void serialize(const T& obj, std::ostream& os) {
        for_each(reflect(T), [&](auto member) {
            std::print("{}: {}\n", member.name(), member.get(obj));
        });
    }

    class Person {
    public:
        Person(const std::string& name, int age)
            : name(name), age(age) {}

        std::string getName() const { return name; }
        void setName(const std::string& name) { this->name = name; }

        int getAge() const { return age; }
        void setAge(int age) { this->age = age; }

    private:
        std::string name;
        int age;

        REFLECT_PROPERTIES(
            (name, "Name of the person"),
            (age, "Age of the person")
        )
    };

    int main() {
        Person person("Alice", 30);

        auto properties = reflect::getProperties<Person>();

        for (const auto& prop : properties) {
            std::print("Property: {} ({})\n", prop.name, prop.description);
            
            auto value = reflect::get(person, prop.name);
            std::print("Value: {}\n", value);

            if (prop.name == "age") {
                reflect::set(person, prop.name, 31);
            }
        }

        std::print("Updated age: {}\n", person.getAge());

        return 0;
    }
    

    template<typename T>
    void printTypeInfo() {
        constexpr auto info = reflect(T);
        std::print("Type name: {}\n", info.name());
        std::print("Member count: {}\n", info.members().size());
    }
    

    template<typename T>
    void printAllMembers(const T& obj) {
        for_each(reflect(T), [&](auto member) {
            std::print("{}: {}\n", member.name(), member.get(obj));
        });
    }

Happily using iostreams since Turbo C++ 1.0 for MS-DOS in 1993, and will keep doing so, unless chasing ms optimizations.

I guess that's not what you wanted to say, but I fully agree :)

Imagine making a plain

    struct Point { float x; float y; };

I have a scripting layer in a game that needs to set properties in a C++ Model. I used a single Boost.Describe macro per struct and a generic get/set property. It worked very well and made me get rid of a lot of boilerplate.

https://www.boost.org/doc/libs/develop/libs/describe/doc/htm...

    template<typename T>
    std::string to_json(const T& obj) {
        std::ostringstream oss;
        constexpr auto type_info = reflect(T);

        if constexpr (type_info.is_fundamental()) {
            // Fundamental types (int, float, etc.)
            if constexpr (std::is_same_v<T, bool>) {
                oss << (obj ? "true" : "false");
            } else if constexpr (std::is_arithmetic_v<T>) {
                oss << obj;
            } else if constexpr (std::is_same_v<T, std::string>) {
                oss << "\"" << obj << "\"";
            }
        }
        else if constexpr (type_info.is_enum()) {
            // Enums
            oss << "\"" << type_info.enum_name(obj) << "\"";
        }
        else if constexpr (type_info.is_array() || std::is_same_v<T, std::vector<typename T::value_type>>) {
            // Arrays and vectors
            oss << "[";
            bool first = true;
            for (const auto& elem : obj) {
                if (!first) oss << ",";
                oss << to_json(elem);
                first = false;
            }
            oss << "]";
        }
        else if constexpr (std::is_same_v<T, std::map<typename T::key_type, typename T::mapped_type>>) {
            // Maps
            oss << "{";
            bool first = true;
            for (const auto& [key, value] : obj) {
                if (!first) oss << ",";
                oss << "\"" << key << "\":" << to_json(value);
                first = false;
            }
            oss << "}";
        }
        else if constexpr (type_info.is_class()) {
            // Classes and structs
            oss << "{";
            bool first = true;
            for (const auto& member : type_info.members()) {
                if (!first) oss << ",";
                oss << "\"" << member.name() << "\":" << to_json(member.get(obj));
                first = false;
            }
            oss << "}";
        }

        return oss.str();
    }


    enum class Color { Red, Green, Blue };

    struct Address {
        std::string street;
        std::string city;
        int zip;
    };

    struct Person {
        std::string name;
        int age;
        double height;
        Color favorite_color;
        Address address;
        std::vector<std::string> hobbies;
        std::map<std::string, int> scores;
    };

    int main() {
        Person person {
            "John Doe",
            30,
            175.5,
            Color::Blue,
            {"123 Main St", "Anytown", 12345},
            {"reading", "hiking", "coding"},
            {{"math", 95}, {"history", 88}, {"science", 92}}
        };

        std::cout << to_json(person) << std::endl;

        return 0;
    }

From there a lot of functionality for making statements about what something is has been bolted on to the side of what is really a very sophisticated type-aware preprocessor, and it shows. It's very painful to use it when you go from the core C++ language to the template, because the semantics are very different. Which the same can be said of C++->Preprocessor.

I think proper reflection should be a core part of the language that can be evaluated at compile-time with simple constructs. It's hard to articulate specifics but I think this proposal greatly simplifies working with type metadata to the degree that it's an approachable problem without using someone else's library. This proposal seems to do that in my opinion, and I think even some of the weaker programmers I've worked with could use this effectively.

This was a video game mod, essentially. I needed to create a text interface to modify settings for any other mod that might be installed. Other mods would simply implement a settings class with certain attributes, then I could list out all fields and their types. The list was processed into a sort of tree presented through the chat interface. From there I can generate code to modify that settings class from outside its assembly and raise value change events.

The reflection part of that was extremely simple, but just because that's how C# works. C# makes a task like this almost trivial.

At my current job, we have a similar thing. Classes decorated with attributes. We inspect them and check the generic type they implement. This way we register message handlers by their message type dynamically. You write a handler class and it simply works.

Windows Forms had a PropertyGrid control which did the same thing as my text interface, but with a grid of properties you can edit freely.

Most of this stuff is typically done at runtime. But you could have it be static if you wanted. A precious job did this to access the backing array inside of a List<> object. I offer no explanation or excuse for that one.

Because the library doesn’t need to allocate unless the underlying types being parsed to do, it has been constexpr since C++17 too.

A bunch of people have used libraries that use macros for reflection like or PFR to integrate other C++ JSON Libraries too.

I am not disagreeing, just more saying what we have now.

They have a reference implementation on godbolt under clang, so you can play around with that. I did not try it yet.

It's nice to know I can just transition to C++26 to fix this.

[1] https://news.ycombinator.com/item?id=32236447

Yes, there is magic_enum already - and we based this implementation on the core of magic_enum, but refocused for C++20, using some of the key features of this language version such constexpr algorithms, std::source_location and concepts; we also improved on and expanded the API.

Looks like it did very well in St. Louis!

I do like the examples that I see there.

This seems like the kind of language feature that I might not make much use of directly in general application code, but would wrap up in utility functions or use via lower-level libraries that the application code builds on. E.g., they showed command-line parsing, but I could also see this for benchmarking and testing frameworks to automatically find the workloads and tests in a non-hacky way.

I also wonder about how this feature interacts with translation units or modules and linkage, though. I'm reminded of the static initialization order fiasco; this seems like it might open up issues that make that look tame by comparison. (Not a complaint; I'm actually looking forward to this.)

There are still a few gotchas being ironed out, there was a talk at ACCU about many corner cases.

But the `member_number` functions in § 3.2 look disturbing to me. It's not discernible how invalid arguments are handled. Normally I'd look at generated assembly to answer a question like that, but this probably doesn't make sense with compile-time-fu (`constexpr`)…

Obviously it’s not suitable for dev builds, I don’t think anyone uses it for that. For release builds you would want to clear caches anyway.

Swift got into this mess early in it's lifecycle and it's type checking is still more expensive than the rest of the compiler combined, and unpredictable on top of that.

    template<typename T>
    T my_construct() { T result; return result; }

edit: you get pseudo call-by-name as a bonus.

    struct PolyReturn {
      const int value;
      operator int() const { return value; }
      operator bool() const { return value > 0; }
    };

It definitely can, and it will be faster and more type-safe than doing it at runtime. But if you do want to do it at runtime, well, it's possible to implement runtime reflection as a library on top of compile-time reflection, so someone will probably do that.

And while it can currently be replaced with templates alone in fairly old versions of C++ (C++14 is the oldest I think), compile times are egregious unless you use very new, shiny features.

And as much as I am pro "move to new shiny C++", one of the big commercial uses of Qt is in semi-embedded applications like car entertainment centers where you are stuck with whatever (often outdated) toolchain your SOC source relies on. So pushing for shiny new Qt risks either splitting Qt in half or abandoning a lot of very well paying users.

I mean, GCC also has some helper tools used to compile C++ code and we don't talk about "replacing them".

Why people want to remove moc from Qt?

See also: https://github.com/cplusplus/networking-ts