[FR]: Allow users to include GoogleTest headers and use `import std` in their code

[davidhunter22]

Does the feature exist in the most recent commit?

No. I could not find any open or closed issues discussing this.

Why do we need this feature?

I believe many users are looking to migrate to using modules, often with using import std; as a first step.
All major compilers now support import std;
CMake support s still experimental but I suspect this will change soon at least for import std;
It is extremely difficult to use GoogleTest in this scenario at present, you often have to do tricks like create empty dummy standard library headers so the #include inside the GoogleTest headers don't actually include anything other than include an empty file!

Describe the proposal.

This proposal is to allow users of GoogleTest to migrate their code to use import std; which at the moment is very hard, almost impossible, without using a lot of tricks

About this proposal

1. Any existing users should see no change, they have to opt in by defining GTEST_BUILD_USING_STD_MODULE or equivalent macro
2. It does not assume anything about how consumers are building their code, it does not require them to use CMake or a package manager
3. It does not propose allowing GoogleTest itself to be build using import std;, I would be happy to do this work if people wanted
4. It is not a proposal to build GoogleTest as a module.
5. It does not require GoogleTest itself to be build with a compiler that supports import std; However the compiler used to build the GoogleTest library and the compiler used to build the users code which links to the GoogleTest library do need to be ABI compatible, but that's not specific to the use of import std;

Currently the header files of GoogleTest include headers from the standard library

#include <vector>

If a user I want to migrate my code to use import std; they can get compiler failures or at the very least a polluted global namespace when I also include the current GoogleTest headers.

In effect we end up with the following

    import std; // User code
    #include <vector> // Via #include of a GoogleTest header

I believe that doesn't compile on any compiler as of today and have been told it is very difficult to do for "reasons". So how about

    #include <vector> // Via #include of a GoogleTest header
    import std; // User code

Well that does compile, mostly, but it throws away the main reason for modules, which is interface encapsulation. So on MSVC the following will compile, similar stuff happens for other compilers and standard libraries

    #include <vector>
    import std;
    std::_Iterator_base x;  // Magic internal symbol that leaks

So all the internal symbols and macros of the standard library will still pollute any user. You are also paying the compile costs of both the #include and the import std;. This may not be so bad if users could use GoogeTest as a module itself as it would be able to control it's own visible interface but that is another topic! In general from experience in a more complex code base using multiple third party libraries it is extremely difficult to avoid arbitrary ordering of #include and import std; In general even if compilers do manage to allow arbitrary mixing of #include and import doing so, I believe will still be fragile and poor practice.
Note there are a few cases where you do need to include a header, so

#include <version>   // For feature test macros
#include <stddef.h> // For offsetof
import std;

Generally this is most to access things only available as macros or C functions not in the standard library. For more info see https://wg21.link/p2654

So the proposal in the issue is to macro guard all #include of the standard library in the GoogleTest public headers. For instance

#if defined(GTEST_BUILD_USING_STD_MODULE)
    import std;
#else
    #include <string>
#endif

Note the macro name can be anything I just picked this as an example.
Also note there is an import std;. This is to make sure the headers can stand alone. It's not actually required as the users could always do a import std; before the #include of the GoogleTest header as all exported standard library names would then be visible, with the exception of macros.

Is the feature specific to an operating system, compiler, or build system version?

No.

It does not require any change to the build of GoogleTest itself so all current supported stuff should work. This is true even if GoogleTest is built for a user by a package manager like VCPKG.

In consumer code it will obviously needs a compiler that supports import std; and to switch on any relevant flags etc... to make this work.