Create a better library developing experience with compiler generated interfaces.

[LouChiSoft]

Not sure if this would actually be a Cpp2 improvement or a C++ improvement in general. But I figured that if Cpp2 exists in this bubble where no code exists and you can do what you want as Herb said in one of his CPPCon talks on the the matter than this might be a good place to experiment.

I was learning one of the other "C++ successor experiements", Rust, and one of the things I really enjoyed about the language was how easy it is to make shareable crates (libraries). It's not perfect because they are designed to be shared as source rather than as precompiled code which limits it in scenarios where you can't share source code. This has led to several attempts at creating some kind of ABI crate that can take a Rust crate and generate a library for you.

I think that Cpp2/C++ could take this idea and run with it. One of the main improvements Cpp2/C++ could make over the Rust approaches is that in most of the Rust crates they end up using a C library for the stable ABI and then providing a crate that includes wrapped interop functions to call into that C library. Because C++ has a stable ABI that wouldn't be needed.

The two methods I could see being useful would be:

• The Rust approach: There is a file, usually called lib.rs, that acts as an entry point into the library. The compiler can then look at all the exports in that file, as well as an other imported files to build a tree of what the library makes available. cppfront would then extract only the required definitions into a single include file that could then be imported before lowering the rest of the code into C++ code to be compiled by the compiler.
• The C# approach: This would be very similar as the Rust approach, only instead of having a single entry point file that is a starting point for the compiler it would just scan each file on it's own and see what is being exposed.

I know it's not necessarily a language feature or function, but I do feel like it would make writing libraries in Cpp2 much simpler and less prone to errors as the compiler would be the one responsible for creating your library interface. Any code changes you make would be automatically reflected in the generated interface file and you would no longer need to mess around with things like __declspec(dllimport) etc on Windows for example.

Would love feedback on the suggestion.

[JohelEGP]

I was wondering if we could use the C++ modules export keyword for also exporting library symbols.
But those are orthogonal concepts (I asked on the Cpplang slack: https://cpplang.slack.com/archives/C92GZLCSE/p1700658714626929).

For certain headers (see #594 (comment)),
Cppfront already generates a header of declarations that can serve as the interface of a library.

[LouChiSoft]

That's interesting it's certainly in the right direction of where I was hoping something like this could go. But I was also thinking along what seems to be the same lines as you where you could have a keyword like export to explicity say "I want this exposed" and anything not marked with export or something similar would be ommited from the interface file. I do think there are definite benefits to being default private as you are less likely to accidentally expose something you didn't mean to by having to explicitly export it.

Also as a quick follow up question, hopefully not too much of a tangent: I noticed #594 uses both cpp2 and h2 files. Has there been any consideration into forcing (pure) Cpp2 to be a single file-typed language. Again when exploring Rust and other languages like C# and Zig they all have just 1 file type that encourages storing your all your code for a specific thing in a single file. Of course you can go against the encouragement, partial classes in C#, putting your impl block in Rust in a different file etc. but you would have to go out of your way to do it. Again I think it would simplify the language if you just had 1 expected file type and a compiler that understands what the best way to compile that efficiently is.

As an example in a perfect world I'd love to be able to take 10 cpp2 files each containing a separate class, compile that to a library and get as my output: my_library.dll and my_library.cpp2 the latter of which can thatn be included in my_program.cpp2 and compiled to an executable

[JohelEGP]

The first part of #120 (comment) is still true (emphasis mine):

Cpp2 is a modules-first design, and Cpp2 won't have header files or separate declarations from definitions

Commit 347c1c2 added support for .h2 header files.

As an example in a perfect world I'd love to be able to take 10 cpp2 files each containing a separate class, compile that to a library and get as my output: my_library.dll and my_library.cpp2 the latter of which can thatn be included in my_program.cpp2 and compiled to an executable

You can probably already do that with C++ modules.
With CMake 3.28 and a single SHARED library with multiple source files.

[LouChiSoft]

The first part of #120 (comment) is still true (emphasis mine):

Cpp2 is a modules-first design, and Cpp2 won't have header files or separate declarations from definitions

So for my understanding, maybe I am misunderstanding, even though .h2 files are emitted by cppfront the end goal is that when you compile a library you would get a library and a module to import instead of a header to include? Or is the .h2 file a module itself, just with a different file extension?

You can probably already do that with C++ modules.
With CMake 3.28 and a single SHARED library with multiple source files.

While I am certain you are right, I think that for many people even now with C++20 out and C++23 on it's way that it's still not the default. And I think for source management simplicity that making it the default that you have to go choose to do something different would help. Maybe I am wrong on this point, but from my perspective the crates and .NET assemblies (while not pre-compiled) are so much more convenient to build.

[JohelEGP]

The commit message from fab2f5f might shed some light into that.

[LouChiSoft]

I see, it's a work in progress. I'll be happy to watch there this goes. Thanks