This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[Accepted as a DR at the November, 2022 meeting, as part of paper P2615R1 (Meaningful exports).]
According to 10.2 [module.interface] paragraph 1, export does not interfere with other definitions; paragraph 3 merely requires that it appear in a declaration that declares at least one name. 13.1 [temp.pre] paragraph 4 prevents using an export-declaration as the declaration of a template-declaration.
With some interpretation, these rules appear to allow various useless constructs like:
template export void f(); export template void f(); export template<> void g(int); template<> export void g(int); export template<class T> struct trait<T*>;
Simply forbidding them in 10.2 [module.interface] paragraph 3 would also prohibit their appearance in export blocks:
export { template<class> struct A; template<class T> struct A<T*>; }
It is already the case that the closely-related example
export { template<class T> struct A {A(non_deducible<T>);}; template<class U> A(U) -> A<find_param<U>>; }
is disallowed, although a fix is pending in EWG.
Suggested resolution: Forbid the direct use of the export keyword in these contexts but continue to allow them (and perhaps more) in export { }.
Notes from the February, 2021 teleconference:
CWG agreed with the suggested direction.
Notes from the 2022-05-20 CWG telecon:
CWG agreed with the wording suggested by Herring; forwarding to EWG for approval.