Title
Suppressing argument-dependent lookup via parentheses
Status
cd2
Section
6.5.4 [basic.lookup.argdep]
Submitter
Mike Miller

Created on 2008-07-29.00:00:00 last changed 143 months ago

Messages

Date: 2009-10-15.00:00:00

[Voted into WP at October, 2009 meeting.]

Date: 2009-09-15.00:00:00

Proposed resolution (September, 2009):

Change 6.5.4 [basic.lookup.argdep] paragraph 1 as follows:

When an unqualified name is used as the postfix-expression in a function call (7.6.1.3 [expr.call]) is an unqualified-id, other namespaces not considered during the usual unqualified lookup (6.5.3 [basic.lookup.unqual]) may be searched, and in those namespaces, namespace- scope friend function declarations (11.8.4 [class.friend]) not otherwise visible may be found. These modifications to the search depend on the types of the arguments (and for template template arguments, the namespace of the template argument). [Example:

    namespace N {
      struct S { };
      void f(S);
    }

    void g() {
      N::S s;
      f(s);      // calls N::f
      (f)(s);    // error: N::f not considered; parentheses prevent argument-dependent lookup
    }

end example]

Date: 2008-09-15.00:00:00

Proposed resolution (September, 2008):

Change 6.5.4 [basic.lookup.argdep] paragraph 1 as follows:

When an unqualified name is used as the postfix-expression in a function call (7.6.1.3 [expr.call]) is an unqualified-id, other namespaces not considered during the usual unqualified lookup (6.5.3 [basic.lookup.unqual]) may be searched...
Date: 2008-09-15.00:00:00

Notes from the September, 2008 meeting:

The CWG agreed that the suppression of argument-dependent lookup by parentheses surrounding the postfix-expression is widely known and used in the C++ community and must be preserved. The wording should be changed to make this effect clearer.

Date: 2008-07-29.00:00:00

During the discussion of issue 704, some people expressed a desire to reconsider whether parentheses around the name of the function in a function call should suppress argument-dependent lookup, on the basis that this is overly subtle and not obvious. Others pointed out that this technique is used (both intentionally and inadvertently) in existing code and changing the behavior could cause problems.

It was also observed that the normative text that specifies this behavior is itself subtle, relying an a very precise interpretation of the preposition used in 6.5.4 [basic.lookup.argdep] paragraph 1:

When an unqualified name is used as the postfix-expression in a function call...

This is taken to mean that something like (f)(x) is not subject to argument-dependent lookup because the name f is used in but not as the postfix-expression. This could be confusing, especially in light of the use of the term postfix-expression to refer to the name inside the parentheses, not to the parenthesized expression, in 12.2.2.2 [over.match.call] paragraph 1. If the decision is to preserve this effect of a parenthesized name in a function call, the wording should probably be revised to specify it more explicitly.

History
Date User Action Args
2010-03-29 00:00:00adminsetstatus: dr -> cd2
2009-11-08 00:00:00adminsetmessages: + msg2423
2009-11-08 00:00:00adminsetstatus: tentatively ready -> dr
2009-09-29 00:00:00adminsetmessages: + msg2290
2009-09-29 00:00:00adminsetstatus: drafting -> tentatively ready
2009-03-23 00:00:00adminsetstatus: review -> drafting
2008-10-05 00:00:00adminsetmessages: + msg1763
2008-10-05 00:00:00adminsetmessages: + msg1762
2008-10-05 00:00:00adminsetstatus: open -> review
2008-07-29 00:00:00admincreate