This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 3441. Misleading note about calls to customization points

Section: 16.4.5.2.1 [namespace.std] Status: Open Submitter: Michael Park Opened: 2020-05-08 Last modified: 2020-10-02

Priority: 1

View other active issues in [namespace.std].

View all other issues in [namespace.std].

View all issues with Open status.

Discussion:

P0551 (Thou Shalt Not Specialize `std` Function Templates!) added a clause in [namespace.std]/7:

> Other than in namespace `std` or in a namespace within namespace `std`, a program may provide an overload for any library function template designated as a customization point, provided that (a) the overload's declaration depends on at least one user-defined type and (b) the overload meets the standard library requirements for the customization point. (footnote 174) [Note: This permits a (qualified or unqualified) call to the customization point to invoke the most appropriate overload for the given arguments. — end note]

Given that `std::swap` is a designated customization point, the note seems to suggest the following:

>     namespace N {
>       struct X {};
>       void swap(X&, X&) {}
>     }

>     N::X a, b;
>     std::swap(a, b); // qualified call to customization point finds N::swap?

This is not what happens, as the call to `std::swap` does not find `N::swap`.

[2020-07-17; Priority set to 1 in telecon]

Related to 3442.

[2020-09-11; discussed during telecon]

The note is simply bogus, not backed up by anything normative. The normative part of the paragraph is an unacceptable landgrab on those identifiers. We have no right telling users they can't use the names `data` and `size` unless they do exactly what we say `std::data` and `std::size` do. The library only ever uses `swap` unqualified, so the effect of declaring the others as designated customization points is unclear.

The rule only needs to apply to such overloads when actually found by overload resolution in a context that expects the semantics of the customization point.

Frank: do we need to designate `operator<<` as a customization point? Users overload that in their own namespaces all the time.

Walter: This clearly needs a paper.

[2020-10-02; status to Open]

Proposed resolution:

This wording is relative to N4861.

1. Modify 16.4.5.2.1 [namespace.std] as indicated:

   > -7- Other than in namespace `std` or in a namespace within namespace `std`, a program may provide an overload for any library function template designated as a customization point, provided that (a) the overload's declaration depends on at least one user-defined type and (b) the overload meets the standard library requirements for the customization point. (footnote 173) [Note: This permits a (qualified or unqualified) call to the customization point to invoke the most appropriate overload for the given arguments. — end note]