Reflection for C++26

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

Compile-time (“static reflection”)

RTTI is a super vital feature for deserializing without having to generate code or write a ton of tedious boilerplate. I'd be very happy with RTTI in C++ and my life would be instantly easier if there were RTTI in typescript so I didn't have to use any of the hacky solutions out there for deserializing JSON on backends without RTTI.

I suppose C++'s template system might be able to generate JSON deserializers with static reflection as well

You don't need RTTI to deserialize data in a clean way. What you need is return-type polymorphism. Haskell has this and it makes writing serializers and deserializers symmetric and totally painless.

Return type polymorphism and inheritance doesn't mix very well.

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.

> I suppose C++'s template system might be able to generate JSON deserializers with static reflection as well

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.

Having implemented reflection in languages like C(++), before, it is most certainly not bloat-free. There are sorts of 'obvious' things programmers do (like enum-reflection) that end up injecting strings all over the place. The overhead is (worst case) proportional to the source-code size, in those cases. In other cases, you end up with bloat proportional to heavily-utilized template libraries. However, unless the reflection system is very clever, i.e., exposes enough information to the linker to strip duplicate-ish symbols, you end up with a bunch of reflection copies.

Yeah if you ask me, inheritance is the one to go. Every time. Inheritance just makes things more complicated. It’s not a great tool of abstraction.

C++ has both return type polymorphism and inheritance. What it doesn't have is the kind of type inference that Haskell has. Its type inference is very limited.

extern templates address the issue of having multiple instances of a template being expanded inline, with only minimal mess and fuss. (A way to prevent inlining of templated code would have been nice too).

I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also speeds up compilation because it isn’t recompiling the same header files over and over again.

You can't have two functions that differ in just the return type in C++

It's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.

You can sort of do it so long as the return type is a template parameter.

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

You can, if you abuse C++ enough. I needed this very thing for a custom DSL.

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

https://cppinsights.io/s/f0b9976f

That's called a "unity build", build systems such as cmake support it. It has its pros and cons.

Do things that don’t scale :)

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.

And while it helps with compile time (especially with mediocre compilers like MSVC where a large time is spent in the front-end), it doesn't help with stripping unneeded code/data compared to LTO.

It does significantly speed up clean builds in many cases, to the point that those clean builds can even be faster than many "incremental" builds in some cases.

That's not polymorphism as that template parameter won't be deduced in any context and you will always have to explicitly instantiate the template.

That is still polymorphic, but as I mentioned C++ does not do the kind of type deduction that Haskell supports so you do have to explicitly instantiate the template. However, you can instantiate it based on context, for example using decltype.

You certainly can and I know there are several JSON libraries that do it. The gist of it is to write a struct and overload the conversion operator for the set of return types you want to support, for example overload the conversion operator to int and std::string. As soon as the instance of that struct is used in a context that needs an std::string, then it calls the string overload.

challenge accepted: https://gcc.godbolt.org/z/bGdP79aEj

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

I do not know of any compiler that can compile different parts of a translation unit in parallel. But plenty of systems (including the venerable `make -j`) can compile separate translation units in parallel because they are independent.

You don't want to clear caches for release builds. That just makes release builds unnecessarily slow and impedes the flow of Continuous Deployment. You just need to have separate caches for different build flags, including a dedicated cache for release builds.