Proposed resolution (10/00):
A template name may have linkage (6.6 [basic.link]).
to:
A template name has linkage (6.6 [basic.link]).
A non-member function template
can have internal linkage; any other template name shall have external
linkage. Entities generated from a template with internal linkage are distinct
from all entities generated in other translation units.
Mike Ball: I cannot find anything in the standard that tells me the meaning of
a storage-class-specifier on a function template declaration. In
particular, there is no indication what effect, if any, it has on the storage
class of the instantiations. There is an explicit prohibition of storage-class-specifiers
on explicit specializations. For example, if we have So what does the specifier mean? Lacking a direct statement in
the standard, I see the following posibilities, in my preference order. From John Spicer The standard does say that a namespace scope template has external linkage
unless it is a function template declared "static". It doesn't explicitly
say that the linkage of the template is also the linkage of the instantiations,
but I believe that is the intent. For example, a storage class is
prohibited on an explicit specialization to ensure that a specialization
cannot be given a different storage class than the template on which it
is based.
John: Agreed.
John: That would mean prohibiting static function templates.
I doubt those are common, but I don't really see much motivation for getting
rid of them at this point.
John: I can't find it either. The "inline" case seems to
be addressed, but not static. Surely this is an error as, by definition,
a static template can't be used from elsewhere. Proposed resolution (10/00):
template<class T> static int foo(T) { return sizeof(T); }
does this generate static functions for all instantiations? By
9.2.2 [dcl.stc]
the storage class applies to the name declared in the declarator, which
is the template foo , not an instantiation of foo , which
is named with a template-id. There is a statement in clause
14 that template names have linkage, which supports the contention that
" static " applies to the template, not to instantiations.
Of course, if anybody can find some concrete statement, that would settle
it.
Mike: This makes sense, but I couldn't find much support
in the document. Sounds like yet another interpretation to add to
the list.
The standard does not talk about the linkage of instantiations, because
only "names" are considered to have linkage, and instances are not really
names. So, from an implementation point of view, instances have linkage,
but from a language point of view, only the template from which the instances
are generated has linkage.
Mike: Which is why I think it would be cleaner to eliminate
storage class specifiers entirely and rely on the unnamed namespace.
There is a statement that specializations go into the namespace of the
template. No big deal, it's not something it says, so we live with
what's there.
"export" is an additional attribute that is separate from linkage, but
that can only be applied to templates with external linkage.
Mike: I can't find that restriction in the standard,
though there is one that templates in an unnamed namespace can't be exported.
I'm pretty sure that we intended it, though.
A template name may have linkage (6.7 [basic.link]).
to:
A template name has linkage (6.7 [basic.link]).
A non-member function template
can have internal linkage; any other template name shall have external
linkage. Entities generated from a template with internal linkage are distinct
from all entities generated in other translation units.