cppfront module syntax?

[Ariaszzzhc]

Does cppfront have any plans for modules?

I found that the existing examples of cppfront still use header files (*.h2). I think cppfront should focus on modules instead of using header files.

Even though mainstream compilers(like clang, gcc) don't fully support C++ modules yet, cppfront is like TypeScript for JavaScript, where the code gets transpiled into cpp code.

So, is it possible that after a cpp2 module is transpiled to cpp, it becomes a header file and a translation unit?

Just like this:

---------------------- cpp2 module ----------------------------

export module mod;

export mod: namespace = {
  hello: () = std::cout << "Hello, World!\n";
}

after transpiled

---------------------- cpp1 header -------------------------------

// .... header guard

namespace mod {
  auto hello() -> void;
}

---------------------- cpp1 file ------------------------------------

// .... include headers

auto mod::hello() -> void {
  std::cout << "Hello, World!\n";
}

This way, cppfront would have its own modules and wouldn't need to worry about whether the C++ compiler supports modules or not.

[DyXel]

This seems to be a hot question! In short, module syntax in cppfront hasn't been enabled yet, because Herb is waiting for its support to be solidified across compilers (that is, to simply lower export module mod; and similar syntax to the same thing in the resulting .cppm file to be compiled by the C++ compiler). On the other hand, it is possible control the output of cppfront somewhat to do the latter thing, see here: #594, but at least for now you'd still be #including things the old fashioned way, without getting the benefits of modules.

[hsutter]

@DyXel is correct, it's a hot question and I'm waiting for modules support to solidify.

Quick $0.02: In the meantime, you might be able to use Cpp1 syntax for export and import? After all, it's a design goal for you to still have all Cpp1 at your disposal, and that might be enough to export and import entities that happen to be written in Cpp2 syntax?

I just did a super-quick-and-dirty (and very-partial) test, adapting the example on this page in MS Learn:

export module Example;

#define ANSWER 42

Example_NS: namespace =
{
    f_internal: () -> int = {
        return ANSWER;
    }

    f: () -> int = {
      return f_internal();
   }
}

export Example_NS::f;

I currently have to name this file something.cpp2, and the MSVC compiler wants the output to be an .ixx file so I used cppfront demo.cpp2 -o demo.ixx.

One test seemed to compile.

A slight variation ICEd the MSVC compiler.

Many disclaimers: I didn't test a whole program. I don't know if I'm holding it wrong.

[Ariaszzzhc]

I've tested this little program.

output

//=== Cpp2 type declarations ====================================================


#include "cpp2util.h"

#line 1 ".\\module-demo.cpp2"

#line 5 ".\\module-demo.cpp2"
namespace Example_NS
 {

#line 14 ".\\module-demo.cpp2"
}


//=== Cpp2 type definitions and function declarations ===========================

#line 1 ".\\module-demo.cpp2"
export module Example;

#define ANSWER 42

#line 5 ".\\module-demo.cpp2"
namespace Example_NS
 {
    [[nodiscard]] auto f_internal() -> int;

#line 11 ".\\module-demo.cpp2"
    [[nodiscard]] auto f() -> int;

#line 14 ".\\module-demo.cpp2"
}

export Example_NS::f;


//=== Cpp2 function definitions =================================================

#line 1 ".\\module-demo.cpp2"

#line 5 ".\\module-demo.cpp2"
namespace Example_NS
 {
#line 7 ".\\module-demo.cpp2"
    [[nodiscard]] auto f_internal() -> int{
        return ANSWER; 
    }

#line 11 ".\\module-demo.cpp2"
    [[nodiscard]] auto f() -> int{
      return f_internal(); 
   }
}

Currently this output still has some problem. namespace declaration should not appear before module declaration.

But it looks very nice!

[Ariaszzzhc]

that is, to simply lower export module mod; and similar syntax to the same thing in the resulting .cppm file to be compiled by the C++ compiler

I think cppfront should implement its own module syntax and then let developers choose the transpilation result through configuration.

If the compiler doesn't support modules or the environment can't use modules, then cppfront could be configured to generate headers.