Make rfl::num_fields public

[bryceschober]

• "Fixes" Reflect on the number of fields of a too-complex type at compile time? #451 by making rfl::num_fields "public" by moving it out of the rfl::internal namespace
• Documents my use-case for rfl::num_fields in rfl::Reflector validation.
• Update tests/README.md with easier execution method

[gemini-code-assist]

Summary of Changes

Hello @bryceschober, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request primarily focuses on exposing the rfl::num_fields utility to the public API, addressing a specific issue where it was previously confined to an internal namespace. This change is complemented by updated documentation that illustrates a practical use case for rfl::num_fields in validating rfl::Reflector specializations. Additionally, the test execution instructions have been improved for better developer experience.

Highlights

• Public API Exposure: The rfl::num_fields utility has been moved from the rfl::internal namespace to the top-level rfl namespace, making it part of the public API. This addresses the issue of it being previously confined to an internal namespace.
• Enhanced Reflector Validation Documentation: New documentation has been added to docs/custom_parser.md demonstrating how rfl::num_fields can be used to implement compile-time assertions for rfl::Reflector specializations. This helps ensure that the ReflType and the original class have the same number of fields, improving validation.
• Improved Test Execution Documentation: The tests/README.md has been updated to include instructions for running all tests using ctest, simplifying the overall test execution process for developers.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request promotes rfl::num_fields to a public API by relocating it from the rfl::internal namespace. Documentation updates explain its use in rfl::Reflector validation, and test execution instructions in the README have been improved. I've suggested relocating the header file for the new public API and improving the formatting of a long command in the README.

[gemini-code-assist]

Moving num_fields out of the internal namespace makes it a public API, but it's still defined within a header file located in the internal directory. This is counterintuitive. Consider moving the declaration to a header file directly under include/rfl/ to better reflect its public status. For example, create a new include/rfl/num_fields.hpp and include the internal header for implementation details.

[liuzicheng1987]

@bryceschober , I agree with this one. I think the namespaces should always follow the file structure, wherever possible. It just makes it easier to navigate and find things.

I think what you can also do is to just include a file include/rfl/num_fields.hpp:

#include "internal/num_fields.hpp"

namespace rfl {
  template <class T>
  constexpr std::size_t num_fields = internal::num_fields<T>;
}

[bryceschober]

Fixed.