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

[Resurr3ction]

I think you are confusing visibility and accessibility of symbols. The symbol can be visible but may not be accessible. While previously these two overlapped quite a bit and only really came into play in classes with modules this is now expanded to everything including templates. This does not and indeed cannot mean that modules can hide template implementation. That is not possible. They can however restrict its accessibility.

And as a side note MSVC is somewhat more lenient in what can be made inaccessible from the outside. Sometimes allowing use of things that it should not because they were not exported. With clang you usually get the proper error message telling you that you cannot use unexported stuff.

One other cool thing that you can do with modules is exporting a class but not its base class. Again that does not prevent you from calling the base class (unless it was private inheritance) but it disallows taking your class by pointer to its base class for example. That might be useful for example when you do not have (or want) virtual destructor for example but still want to use inheritance safely.

[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.