Created on 2006-02-17.00:00:00 last changed 178 months ago
[Voted into WP at March, 2010 meeting.]
Proposed resolution (October, 2009):
Change 13.8.3 [temp.dep] paragraph 1 as follows:
In an expression of the form:
postfix-expression ( expression-listopt )
where the postfix-expression is an unqualified-id
but not a template-id, the unqualified-id denotes a dependent name if and only if any of the expressions in the expression-list is a type-dependent expression (13.8.3.3 [temp.dep.expr])...
Change 13.8.4.2 [temp.dep.candidate] paragraph 1 as follows:
For a function call that depends on a template parameter, if the function name is an unqualified-id
but not a template-id, or if the function is called using operator notation, the candidate functions are found using the usual lookup rules (6.5.3 [basic.lookup.unqual], 6.5.4 [basic.lookup.argdep]) except that:
For the part of the lookup using unqualified name lookup (6.5.3 [basic.lookup.unqual]), only function declarations
with external linkagefrom the template definition context are found.For the part of the lookup using associated namespaces (6.5.4 [basic.lookup.argdep]), only function declarations
with external linkagefound in either the template definition context or the template instantiation context are found.
Note (June, 2006):
Although the notes from the Berlin meeting indicate that argument-dependent lookup for template-ids is under-specified in the Standard, further examination indicates that that is not the case: the note in 13.10.2 [temp.arg.explicit] paragraph 8 clearly indicates that argument-dependent lookup is to be performed for template-ids, and 6.5.4 [basic.lookup.argdep] paragraph 4 describes the lookup performed:
When considering an associated namespace, the lookup is the same as the lookup performed when the associated namespace is used as a qualifier (6.5.5.3 [namespace.qual]) except that:
Any using-directives in the associated namespace are ignored.
Any namespace-scope friend functions declared in associated classes are visible within their respective namespaces even if they are not visible during an ordinary lookup (11.8.4 [class.friend]).
Notes from the April, 2006 meeting:
The consensus of the group was that template-ids should not be treated differently from unqualified-ids (although it's not clear how argument-dependent lookup works for template-ids), and that internal-linkage functions should be found by the lookup (although they may result in errors if selected by overload resolution).
According to 13.8.4.2 [temp.dep.candidate],
For a function call that depends on a template parameter, if the function name is an unqualified-id but not a template-id, the candidate functions are found using the usual lookup rules (6.5.3 [basic.lookup.unqual], 6.5.4 [basic.lookup.argdep]) except that:
For the part of the lookup using unqualified name lookup (6.5.3 [basic.lookup.unqual]), only function declarations with external linkage from the template definition context are found.
For the part of the lookup using associated namespaces (6.5.4 [basic.lookup.argdep]), only function declarations with external linkage found in either the template definition context or the template instantiation context are found.
It is not at all clear why a call using a template-id would be treated differently from one not using a template-id. Furthermore, is it really necessary to exclude internal linkage functions from the lookup? Doesn't the ODR give implementations sufficient latitude to handle this case without another wrinkle on name lookup?
(See also issue 524.)
History | |||
---|---|---|---|
Date | User | Action | Args |
2010-03-29 00:00:00 | admin | set | messages: + msg2737 |
2010-03-29 00:00:00 | admin | set | status: ready -> cd2 |
2009-11-08 00:00:00 | admin | set | messages: + msg2378 |
2009-11-08 00:00:00 | admin | set | status: drafting -> ready |
2006-06-23 00:00:00 | admin | set | messages: + msg1378 |
2006-04-22 00:00:00 | admin | set | messages: + msg1336 |
2006-04-22 00:00:00 | admin | set | status: open -> drafting |
2006-02-17 00:00:00 | admin | create |