Add RFC about C++20 modules support

[isaevil]

Description

Add a comprehensive description of proposed changes

Fixes # - issue number(s) if exists

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

• bug fix - change that fixes an issue
• new feature - change that adds functionality
• tests - change in tests
• infrastructure - change in infrastructure and CI
• documentation - documentation update

Tests

• added - required for new features and some bug fixes
• not needed

Documentation

• updated in # - add PR number
• needs to be updated
• not needed

Breaks backward compatibility

• Yes
• No
• Unknown

Notify the following users

List users with @ to send notifications

Other information

[mropert]

I would add a question about plans to handle transitive inclusion of the STL.
Since modules tend to break down when some project use the STL through #include directives and other through import std this should be considered.
I would recommend either toggling all #include into import when using TBB as a module, or at least provide a define to toggle between the two options.

[isaevil]

Do you mean that, since declarations in std module are attached to "unspecified" module, ABI compatibility may be broken when std module and standard headers are used in the same application?

[mropert]

Most (all?) compilers will support something like this:

#include <vector>
import std;

But not this:

import std;
#include <vector>

This is also true if the includes/imports happens transitively by import/including files that themselves do import/includes.
So if people do import tbb, then need to be able to control how transitive inclusion of the STL by TBB will be done. The most common I have seen is that when in module mode all #include should be turned into import directives, but if you're worried this is too drastic you can provide a define that allow people to pick a strategy.

[isaevil]

It seems more like a compiler implementation limitation, not limitation of TBB named module itself, so I wouldn't say it is an open question for supporting modules in TBB. But we'll keep that issue in mind for sure, thanks.

[mropert]

I'm pretty sure it's a limitation of how modules work in practice (and maybe even on spec, that part isn't entirely clear).

Either way, it's defintely a question you'll have to solve because else you'll get constant complaints from module users.

[vossmjp]

LGTM

[akukanov]

The RFC looks good for initial acceptance and implementation. Open questions can be additionally clarified though.

[akukanov]

Are there usage scenarios that are not covered by the suggested approach with test_tbb_header?
If the only practical difference is for using import instead of #include, then the API availability checks seem sufficient.

Also, is there any practical way to check that only the desired public APIs are exported, and nothing else?

[isaevil]

Are there usage scenarios that are not covered by the suggested approach with test_tbb_header?
If the only practical difference is for using import instead of #include, then the API availability checks seem sufficient.

I would say perhaps ABI compatibility check (combining TUs compiled with modules and headers) is not implemented currently, but my understanding is that can be done the similar way as with test_tbb_header_secondary.cpp.

Also, is there any practical way to check that only the desired public APIs are exported, and nothing else?

For now I can only think of marking somehow in headers what we believe is a public API (we usually have inline-namespace at the bottom of header with using-declarations) and auto-generating a module from that and comparing it with tbb.cppm.

[akukanov]

I would say perhaps ABI compatibility check (combining TUs compiled with modules and headers) is not implemented currently, but my understanding is that can be done the similar way as with test_tbb_header_secondary.cpp.

Should we then add this to the testing plan and close the question, or are there more nuances?

Running the whole test suite with module imports instead of includes would check if the functionality is not just accessible but also properly usable. However, based on what we know of the way modules work and the internals of our implementation, would that add sufficient value? I feel like it would not.