https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122908
--- Comment #11 from Bernardo Negri <b.gomes.negri at gmail dot com> --- (In reply to Nathaniel Shead from comment #10) > (In reply to Bernardo Negri from comment #9) > > (In reply to Nathaniel Shead from comment #6) > > > What makes you say that? Within a module interface unit, only in a private > > > module fragment is an exposure allowed, by > > > https://eel.is/c++draft/basic.link#17. > > Confusion about the difference between the private module fragment and the > > global module fragment. Thank you for clarifying, I was not reading the spec > > correctly. > > > > However, this just makes me more confused about the intended use for global > > module fragments, since it is possible to violate exposure rules by merely > > #include ing a header. > > > > Consider a 3rd party library: > > // class.h > > template <typename T> > > static size_t getSize(const std::vector<T> &list) { > > return list.size(); > > } > > template <typename T> > > class Class { > > void processList(std::vector<T> list) { > > getSize(list); > > } > > } > > > > This library is fine to use with the traditional .cpp plus header files > > structure (though it is deprecated), but if you try to use it in a project > > with modules, just #include ing it on the GMF is an error according to the > > standard. The only solution I know is with header units, which are not well > > supported by build systems. Are there any other ways? > > Unfortunately not, the header would need to be fixed. For what it's worth, > if the header was included in more than one TU this was always IFNDR > (ill-formed, no diagnostic required) due to the ODR violation; modules has > just made this mandated IF (ill-formed) in more cases. Would it be IFNDR even if it had an include guard (or pragma once). From my understanding of the spec, it would be IFNDR because of [1] and [2]: there would be two different definitions of Class in different TUs (so [1] would apply), but getSize would refer to different entities (that are defined the same way). Therefore, the existence of both of these definitions would run afoul of basic.def.odr#16.5: "corresponding names, looked up according to [basic.lookup], shall denote the same entity". Am I correct? Or do the templates mess everything up? [1] https://eel.is/c++draft/basic.def.odr#16 [2] https://eel.is/c++draft/basic.link#8
