https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124888
--- Comment #10 from Seb James <sebj_coder3 at pm dot me> --- I'm going to make a case for this bug to be bumped in priority. The first premise is that I am a representative example of a C++ application developer who really wants to move their code over to C++ modules and have it compile on a released version of GCC (as well as released versions of other major compilers). The second premise is that I am likely to need std::function to 'wire up' data in my application, especially because C++ modules enforces the good design of avoiding circular dependencies. The third premise is that many developers in my position will decide to write/convert their own code as C++20 modules, but continue to use #include for the standard library. I made the decision to use #include <std_header> instead of import std; or import <std_header_unit>; for these reasons: If I 'import std' to get the standard library then I can run into problems when I try to link another C++ library which itself links to a libstdc++ of a different version. (At the moment I do have this issue and I cannot convert the third party library to modules with import std to solve it.) I cannot use header units because I use one of the most common build systems, CMake. Unfortunately, it doesn't support header units at present. I'm not about to switch out CMake for something that supports header units. I claim that these reasons will make switching to C++ modules in the order "my code first, standard library second" is going to be attractive to a lot of developers wanting to go modules. If you accept my three premises, then I think you have to conclude that this bug is a barrier to modules adoption with GCC in spite of the possible workarounds that exist.
