Module files generated by ddl2cpp

[MeanSquaredError]

In the last few days I've been tinkering with sqlpp23 and I came across an issue with the layout of the modules generated by ddl2cpp

Currently the generated modules look like this:

module;

// Some comments

import std;

#include <sqlpp23/core/name/create_name_tag.h>

import sqlpp23.core;

export module unreal.db.model;

// The table definitions go here

} // namespace unreal::db::model

The problem with this layout is that the C++ standard explicitly prohibits using import statements in the Global Module Fragment (the part between module; and export module unreal.db.model;)
https://eel.is/c++draft/cpp#pre-5

At the start of phase 4 of translation, the group of a pp-global-module-fragment shall contain neither a text-line nor a pp-import.

(However, AFAIK there is nothing in the standard prohibiting the GMF to #include a header, which in turn does import module.name;, only direct import statements in the GMF are prohibited)

Also it seems that even though import statements are disallowed in the GMF by the standard, the compilers allow it. One of the Clang devs confirmed that this is not allowed by the standard and Clang will fix this in the future. I am not sure whether by "fix it" they mean that they will print a warning or just err on it.

There is also a bit of discussion on this subject on Reddit and on Stack Overflow

Additionally the current layout places import std; before #include <sqlpp23/core/name/create_name_tag.h>. Clang does allow it, but they warn that Including headers after import is not well-supported.

That's why I suggest changing the layout of the modules generated by ddl2cpp to something like this:

module;

// Some comments

#include <sqlpp23/core/name/create_name_tag.h>

export module unreal.db.model;

import sqlpp23.core;
import std;

// The table definitions go here

} // namespace unreal::db::model

That is, any includes go into the GMF and all imports go to the beginning of the module purview (the part right after export module unreal.db.model;)

Perhaps this change can be implemented easily if #134 is merged in the code first.

[rbock]

Thanks for the report. Yeah, we should fix this.

Note: As of today, I don't think that I will merge #134:

• We can clean up the current code generation dramatically without using a template engine
• I don't want to add another dependency unless there is a really strong requirement for it.

That said, fixing the _begin_module function should be rather simple, shouldn't it?

[rbock]

PTAL at 86db2ca.