This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115f. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-06
[Voted into WP at October 2004 meeting.]
According to 6.6 [basic.link] paragraph 8, "A name with no linkage ... shall not be used to declare an entity with linkage." This would appear to rule out code such as:
typedef struct { int i; } *PT; extern "C" void f(PT);[likewise]
static enum { a } e;which seems rather harmless to me.
See issue 132, which dealt with a closely related issue.
Andrei Iltchenko submitted the same issue via comp.std.c++ on 17 Dec 2001:
Paragraph 8 of Section 6.6 [basic.link] contains the following sentences: "A name with no linkage shall not be used to declare an entity with linkage. If a declaration uses a typedef name, it is the linkage of the type name to which the typedef refers that is considered."
The problem with this wording is that it doesn't cover cases where the type to which a typedef-name refers has no name. As a result it's not clear whether, for example, the following program is well-formed:
#include <vector> int main() { enum { sz = 6u }; typedef int (* aptr_type)[sz]; typedef struct data { int i, j; } * elem_type; std::vector<aptr_type> vec1; std::vector<elem_type> vec2; }
Suggested resolution:
My feeling is that the rules for whether or not a typedef-name used in a declaration shall be treated as having or not having linkage ought to be modelled after those for dependent types, which are explained in 13.8.3.2 [temp.dep.type].
Add the following text at the end of Paragraph 8 of Section 6.6 [basic.link] and replace the following example:
In case of the type referred to by a typedef declaration not having a name, the newly declared typedef-name has linkage if and only if its referred type comprises no names of no linkage excluding local names that are eligible for appearance in an integral constant-expression (7.7 [expr.const]). [Note: if the referred type contains a typedef-name that does not denote an unnamed class, the linkage of that name is established by the recursive application of this rule for the purposes of using typedef names in declarations.] [Example:void f() { struct A { int x; }; // no linkage extern A a; // ill-formed typedef A Bl extern B b; // ill-formed enum { sz = 6u }; typedef int (* C)[sz]; // C has linkage because sz can // appear in a constant expression }--end example.]
Additional issue (13 Jan 2002, from Andrei Iltchenko):
Paragraph 2 of Section 13.4.2 [temp.arg.type] is inaccurate and unnecessarily prohibits a few important cases; it says "A local type, a type with no linkage, an unnamed type or a type compounded from any of these types shall not be used as a template-argument for a template-parameter." The inaccuracy stems from the fact that it is not a type but its name that can have a linkage.
For example based on the current wording of 13.4.2 [temp.arg.type], the following example is ill-formed.
#include <vector> struct data { int i, j; }; int main() { enum { sz = 6u }; std::vector<int(*)[sz]> vec1; // The types 'int(*)[sz]' and 'data*' std::vector<data*> vec2; // have no names and are thus illegal // as template type arguments. }
Suggested resolution:
Replace the whole second paragraph of Section 13.4.2 [temp.arg.type] with the following wording:
A type whose name does not have a linkage or a type compounded from any such type shall not be used as a template-argument for a template-parameter. In case of a type T used as a template type argument not having a name, T constitutes a valid template type argument if and only if the name of an invented typedef declaration referring to T would have linkage; see 3.5. [Example:template <class T> class X { /* ... */ }; void f() { struct S { /* ... */ }; enum { sz = 6u }; X<S> x3; // error: a type name with no linkage // used as template-argument X<S*> x4; // error: pointer to a type name with // no linkage used as template-argument X<int(*)[sz]> x5; // OK: since the name of typedef int // (*pname)[sz] would have linkage }--end example] [Note: a template type argument may be an incomplete type (6.8 [basic.types]).]
Proposed resolution:
This is resolved by the changes for issue 389. The present issue was moved back to Review status in February 2004 because 389 was moved back to Review.