C++20 Modules?

[jowillianto]

This is just a proposal. Please reject if considered unnecessary. I can try to work on this specifically.

i.e:

import reflectcpp;
import reflectcpp.json;

[liuzicheng1987]

@jowillianto , would there be a way to design this such that it is optional? Meaning you could have either modules or headers?

[jowillianto]

As of now, I have no idea and is not really sure. But I will try my best, we probably need a cmake switch to make this work. I have some toy projects of my own that I can test this on.

[jowillianto]

@liuzicheng1987
I have tried the include method with a toy project. The following has to be done:

• Update CMAKE to support the operation
  • A Boolean switch for the modules mode.
  • Defining a compile definition for modules mode and to mask the export keyword. This should be masked to empty string in header mode and export in module mode.
• Update the repository to be module first. i.e. it should support modules first, and then we backward support it with header.
• If the source directory name is not the desired include path, cmake should be updated to perform the copy into a desired path.
• define guards should be kept the same. In header mode, a reflectcpp.hpp have to include all the files in the correct order. No files should include each other, they should be included in the correct order. The define guards prevents compilation error when a user makes a mistake of including a small portion of the library by mistake instead of reflectcpp.hpp.

The toy project is here:

• Include Header Support jowillianto/jowi-generic#1

This means that modules are somewhat backward compatibles, but you definitely cannot use header style inside modules. My suggestion is that:

• reflectcpp main should be guarded inside just reflectcpp.
  Any additional libraries can use the namespace and export reflectcpp.'impl' and so on, they will all import reflectcpp for the relevant parts.
  Hence,
  reflectcpp:field, reflectcpp:object, will all be inside the module reflectcpp.
• Since, this is a big undertaking, I think this requires extensive testing, most problems are gonna come from the style of my old include does not work. Hence, we have to test if includes will still work as expected.

[GregTheMadMonk]

There is a less invasive, although cumbersome way (but any way is essentially like that) that, for example, ArthurSonzogni/FTXUI went. This is also how it is essentially done when you have a thirt-party dependency you want to modularize. The library remains essentially the same, but in src/ directory a file structure is created that mirrors the desired module structure and re-exports declarations that are necessary for the module to work.

E.g. for a library that has an interface file include/foo.hh

#pragma once
namespace foo {
namespace internal {
inline void bar() {}
} // <-- namespace internal
void foo();
} // <-- namespace foo

and a TU src/foo.cc

#include "foo.hh"

void foo::foo() { /* ... */ }

And a corresponding CMake target:

add_library( foo STATIC src/foo.cc )
target_include_directories( foo PUBLIC include/ )

you would create the following interface file src/foo.ixx (or whatever is your extension of choice for this, mine is .xx):

module;
#include <foo.hh>
export module foo;

export namespace foo {
using ::foo::foo;
}

and a new CMake target:

add_library( foo-modules STATIC )
target_link_libraries( foo-modules PRIVATE foo ) # or PUBLIC? I'm not sure tbh
target_sources(
    foo-modules PUBLIC
    FILE_SET foo_ixx_interface
    FILES src/foo.ixx
    TYPE CXX_MODULES
)

You used to need to replace all standard headers with import std if you wanted to use that, but I think it's mostly working fine in compilers by now and not a requirement anymore. CLang doesn't seem to have a lot of problems with modules, at least - I certainly was fine using FTXUI as a module.

P.S. Due to the modules' nature of hiding everything that wasn't exported, it's also worth thinking about what should and should not be internal, or hidden. E.g. rfl::internal::StringLiteral looks like a prime candidate to become just rfl::StringLiteral because it needs to be pus as a type for an NTTP when creating custom class templates that pass strings to rfl:: types

[jowillianto]

I considered the less invasive way and actually preferred upgrading the repo and giving backwards compatibility. I can work on this @liuzicheng1987 in any of the two ways you want !
I am sure this can work.

[jowillianto]

@liuzicheng1987 , if you give your say on this matter on which method to go with, I will start implementing the solution we discussed. After doing this, we should perform a benchmark, on compile speed and on clangd speed. I, personally, prefer the more invasive way and provide good backwards compatibility even though it is a little more cumbersome to perform.

[liuzicheng1987]

@jowillianto , sorry for the late reply on the matter.

Yes, please go ahead and draft a PR using the "more invasive" method you have discussed.

[jowillianto]

Ok. This will probably take a while.