Reflect on the number of fields of a too-complex type at compile time?

[bryceschober]

Background:

I'm implementing an rfl::Reflector for a type that has some member types that reflect-cpp isn't capable of reflecting. (FWIW, these are types from https://github.com/mpusz/mp-units, which I assume probably need a similar deep surgery treatment as your std::chrono::duration support.)

Issue:

As a workaround for the time being, I'm implementing rfl::Reflector for these types to convert to-from primitive underlying types. Since these require manual conversion of each field, I'd love to have a standard compile-time assertion when the number of fields in ReflType doesn't match the full type, as in:

namespace rfl{
    template<>
    struct Reflector<FancyType> {
        struct ReflType {
            float field_1;
            uint64_t field_2;
        };
        static_assert(rfl::fields<ReflType>().size() == rfl::fields<FancyType>().size(),
                      "ReflType must have the same number of fields as actual type");

        // Conversion functions go here..

Is there a different constexpr method that reflect-cpp can provide to implement this compile-time assertion? Obviously, we can implement run-time assertions in our unit tests, but that's less than ideal.

Even more ideally, a rfl::Reflector could do something approximately like this, and have reflect-cpp provide the assertion:

namespace rfl{
    template<>
    struct Reflector<FancyType, SameNumFieldsPolicy> {

[bryceschober]

Ah, now I see that I can use rfl::internal::num_fields<T> for that purpose... but obviously that's not "public". Am I missing a different way to do this?

namespace rfl{
    template<>
    struct Reflector<FancyType> {
        struct ReflType {
            float field_1;
            uint64_t field_2;
        };
        static_assert(rfl::internal::num_fields<ReflType> == rfl::internal::num_fields<FancyType>,
                      "ReflType must have the same number of fields as the actual type");

        // Conversion functions go here..

[liuzicheng1987]

@bryceschober I think we can make that public, that's not a problem

[bryceschober]

Are there other compile-time reflection capabilities that are similarly internal, like field name and type iteration?

[liuzicheng1987]

@bryceschober field names and types are public