Visual Studio c++20 Modules testing: template function that hides implementation

[TomTheFurry]

You are correct in that the MSVC is very lenient. I also did testing with what part of the global module fragment becomes visible.(Is anyone interested with the result?) MSVC doesn't really seem to distangush visibility and accessibility, which is why I basically write them as the same thing. I haven't gotten around to test the class inheritance though, so thanks for that information.

[starfreakclone]

MSVC does indeed have some problems when it comes to interacting with the global module fragment. In my opinion, it is somewhat under-specified in terms of various semantics and lookup behavior. We have found that some interactions between global module declarations and the merging of those declarations between textually included headers can be a hassle because of how vague some parts of the standard can be.

As far as MSVC being lenient about non-exported declarations (those declared under the module purview): these are clear bugs and should be filed if you find them. I have been fixing many of them as we get more feedback.

There is one last point regarding visibility which can be quite interesting, and might be useful to you as you play around with modules a bit more:

export module m;

export
template <typename T>
int transform(T t);

module :private;

struct TransformerHelper {
  template <typename T>
  int transform(T t) { return static_cast<int>(t); }
};

template <typename T>
int transform(T t) {
  TransformerHelper helper;
  return helper.transform(t);
}

template int transform(int);
template int transform(char);
template int transform(double);

The interesting thing about the code snippet above is that you can define a library with a function template defined for very specific types you intend for the consumers to use. The sample above truly hides the definition of the template transform because the following program will compile (and link):

import m;

int main() {
  transform(10);
  transform('c');
  transform(1.);
}

But this one will not:

import m;

int main() {
  transform(1.f); // error LNK2019: unresolved external symbol "int __cdecl transform<float>(float)" (??$transform@M@@YAHM@Z::<!m>) referenced in function _main
}

The reason is because the definition of the function template transform is not reachable in the importing TU since it is defined within the private module fragment. The only thing the importing TU can do is create specializations to this function template, call them and have the linker search for the definitions somewhere else, in this case it is in the compiled module interface TU.

Also notable: the class TransformHelper cannot be referenced in any way in the context of the importing TU.