[Adopted at the February, 2016 meeting.]

Three points have been raised where the wording in 13.9.2 [temp.inst] may not be sufficiently clear.

1. In paragraph 4, the statement is made that

   A class template specialization is implicitly instantiated... if the completeness of the class type affects the semantics of the program...

   It is not clear what it means for the "completeness... [to affect] the semantics." Consider the following example:

           template<class T> struct A;
           extern A<int> a;
   
           void *foo() { return &a; }
   
           template<class T> struct A
           {
           #ifdef OPTION
                   void *operator &() { return 0; }
           #endif
           };
   

   The question here is whether it is necessary for template class A to declare an operator & for the semantics of the program to be affected. If it does not do so, the meaning of &a will be the same whether the class is complete or not and thus arguably the semantics of the program are not affected.

   Presumably what was intended is whether the presence or absence of certain member declarations in the template class might be relevant in determining the meaning of the program. A clearer statement may be desirable.

2. Paragraph 5 says,

   If the overload resolution process can determine the correct function to call without instantiating a class template definition, it is unspecified whether that instantiation actually takes place.

   The intent of this wording, as illustrated in the example in that paragraph, is to allow a "smart" implementation not to instantiate class templates if it can determine that such an instantiation will not affect the result of overload resolution, even though the algorithm described in Clause 12 [over] requires that all the viable functions be enumerated, including functions that might be found as members of specializations.

   Unfortunately, the looseness of the wording allowing this latitude for implementations makes it unclear what "the overload resolution process" is — is it the algorithm in Clause 12 [over] or something else? — and what "the correct function" is.

3. According to paragraph 6,

   If an implicit instantiation of a class template specialization is required and the template is declared but not defined, the program is ill-formed.

   Here, it is not clear what conditions "require" an implicit instantiation. From the context, it would appear that the intent is to refer to the conditions in paragraph 4 that cause a specialization to be instantiated.

   This interpretation, however, leads to different treatment of template and non-template incomplete classes. For example, by this interpretation,

       class A;
       template <class T> struct TA;
       extern A a;
       extern TA<int> ta;
   
       void f(A*);
       void f(TA<int>*);
   
       int main()
       {
           f(&a);    // well-formed; undefined if A
                     // has operator &() member
           f(&ta);   // ill-formed: cannot instantiate
       }
   

   A different approach would be to understand "required" in paragraph 6 to mean that a complete type is required in the expression. In this interpretation, if an incomplete type is acceptable in the context and the class template definition is not visible, the instantiation is not attempted and the program is well-formed.

   The meaning of "required" in paragraph 6 must be clarified.

(See also issues 204 and 63.)