Questions about module support and future direction

[StormLord07]

I'm seeing more and more talk about modules in Glaze and in c++ community overall, Its a great feature, but with a lot of problems that stop me and my friends from moving to modules, as much as we want to do so, and I wanted to ask a few questions about the direction you're planning to take. As said in #1935 bloating glaze.hpp with all headers is "unwise" at least.

• Will the old #include-based approach remain supported, or will modules are intended to replace it?

• Since modules aren’t exactly universal yet (many compilers still choke on STL modules, and mixing them with headers doesn’t feel clean), what’s your approach going to be, not that it's impossible or bad to mix them, just introudeces a lot of strangely formatted code?

• I may be wrong on this, different compilers seem to require different naming conventions and even file extensions for module sources— almost every compiler has a way to override, but that would require manually setting the extension

• Overall, what should people expect in terms of module adoption and stability over the next few releases? How do you suggest getting prepared for modules?

I think a lot of people are curious because modules are still not widely used, and the lack of consistency across compilers makes it a bit of a moving target. So I want to hear other peoples thoughts, questions and answers.

And francly I'm really curious about them, my experiments with modules were, unsuccesfull, when switching compilers, gcc, clang and MSVC.

[stephenberry]

Will the old #include-based approach remain supported, or will modules are intended to replace it?

The plan is to support the #include approach until the codebase drops C++23, which I don't expect to happen for 10 years or more. I do potentially see Glaze having two active versions once we get C++26 reflection, and the C++26 version may forgo the #include approach and only support modules. But, Glaze intends to support C++23 without modules for another decade.

Since modules aren’t exactly universal yet (many compilers still choke on STL modules, and mixing them with headers doesn’t feel clean), what’s your approach going to be, not that it's impossible or bad to mix them, just introduces a lot of strangely formatted code?

Yeah, I've experimented with supporting both approaches at once and it is ugly. So, I'm leaning towards having two separate versions of the codebase once we get C++26, and probably making the C++26 version have the module support. I think it will get easier to transition as compilers get better module support, but I have yet to see a really clean approach in practice.

Overall, what should people expect in terms of module adoption and stability over the next few releases? How do you suggest getting prepared for modules?

Modules are a very new feature and have lots of bugs across the compilers. So, for a project of Glaze's size I don't expect to get a working implementation for another year. There will probably be experiments within the year, but I think it's best to give compilers time to implement them robustly. As far as using the modules, it should be extremely simple once CMake and compilers support the feature. So, you shouldn't have to do much work to prepare for modules as a user.

I'm really excited about modules and I think they'll be fantastic for header only template heavy libraries like Glaze. But, it's a heavy ball to get rolling.