Meaningless template exports
10.2 [module.interface]
Davis Herring

Created on 2019-11-09.00:00:00 last changed 10 months ago


Date: 2022-05-21.12:38:12

Notes from the 2022-05-20 CWG telecon:

CWG agreed with the wording suggested by Herring; forwarding to EWG for approval.

Date: 2021-02-15.00:00:00

Notes from the February, 2021 teleconference:

CWG agreed with the suggested direction.

Date: 2022-11-15.00:00:00

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

Date User Action Args
2023-07-16 13:00:43adminsetstatus: open -> c++23
2023-07-16 13:00:43adminsetstatus: drwp -> open
2023-02-18 18:43:04adminsetstatus: dr -> drwp
2022-12-04 13:22:11adminsetstatus: drafting -> dr
2022-05-21 12:38:12adminsetmessages: + msg6831
2021-02-17 00:00:00adminsetmessages: + msg6490
2021-02-17 00:00:00adminsetstatus: open -> drafting
2019-11-09 00:00:00admincreate