Consider the Clang 'ABI breaking' style for the Vulkan-Hpp module

[sharadhr]

I've been reading the Clang documentation for migrating header libraries to modules, and I took note of the so-called 'ABI-breaking' style.

We already use a similar 'is in module' macro (VULKAN_HPP_CXX_MODULE) to enable import std instead of standard library headers. I would like to extend that to have #define EXPORT export (naturally guarded behind #if defined(...) etc) as detailed in the above documentation. I then hope to simplify the module interface file, as well as completely simplify the generation of the module interface file itself, which currently takes quite a different path to the header generation. This will also probably remove spurious using statements for operator<=> etc.

Naturally this means the generation of the module interface file, as well as its actual contents would change by a lot, and hence I would like some input on this. I don't expect the consumer-facing experience to change.

[M2-TE]

I've seen the current export using ::Symbol way of doing modules in quite a few repos now and I've never been much of a fan of it; especially if you don't have an automated header generator. The "ABI breaking" approach of placing export wrapped in a macro into the headers is much nicer! It avoids the additional maintenance required, not even considering edge cases like the spaceship operator. Would likely need to instead be VULKAN_HPP_EXPORT though.

Since this may require a little bit of time investment, I would first ask what your take on header units is? They are another "transition" mechanic introduced by the standard, albeit not implemented anywhere from what I could tell so far. However, it seems to be the "intended" way of transitioning, where we could just export import <vulkan/vulkan.hpp> for example.

Personally, I prefer some EXPORT macro, since it will work with current toolchains and will continue to work in the future with less maintenance required than the current module. It also enables separating interfaces and implementations (via non-exported helper functions or functions placed in the private module fragment).

[sharadhr]

I've seen the current export using ::Symbol way of doing modules in quite a few repos now and I've never been much of a fan of it

It might have been us who started it, since we were the first big library to announce modularisation 😅

I would first ask what your take on header units is? They are another "transition" mechanic introduced by the standard, albeit not implemented anywhere from what I could tell so far.

Indeed, header units were intended as the transition method, but frankly there's a lot of magic involved, and I don't think it should've been added to the standard. The view is that that Clang may never get header units working. MSVC supports it.

Agreed with export macros; that is the strategy that all the standard libraries have adopted for module std.

[M2-TE]

that is the strategy that all the standard libraries have adopted for module std

very solid argument to adopt it as well