This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.
Section: 16.4.2.2 [contents] Status: CD1 Submitter: Steve Clamage Opened: 2000-04-19 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [contents].
View all issues with CD1 status.
Discussion:
Throughout the library chapters, the descriptions of library entities refer to other library entities without necessarily qualifying the names.
For example, section 25.2.2 "Swap" describes the effect of swap_ranges in terms of the unqualified name "swap". This section could reasonably be interpreted to mean that the library must be implemented so as to do a lookup of the unqualified name "swap", allowing users to override any ::std::swap function when Koenig lookup applies.
Although it would have been best to use explicit qualification with "::std::" throughout, too many lines in the standard would have to be adjusted to make that change in a Technical Corrigendum.
Issue 182(i), which addresses qualification of
size_t, is a special case of this.
Proposed resolution:
To section 17.4.1.1 "Library contents" Add the following paragraph:
Whenever a name x defined in the standard library is mentioned, the name x is assumed to be fully qualified as ::std::x, unless explicitly described otherwise. For example, if the Effects section for library function F is described as calling library function G, the function ::std::G is meant.
[Post-Tokyo: Steve Clamage submitted this issue at the request of the LWG to solve a problem in the standard itself similar to the problem within implementations of library identified by issue 225(i). Any resolution of issue 225(i) should be coordinated with the resolution of this issue.]
[post-Toronto: Howard is undecided about whether it is
appropriate for all standard library function names referred to in
other standard library functions to be explicitly qualified by
std: it is common advice that users should define global
functions that operate on their class in the same namespace as the
class, and this requires argument-dependent lookup if those functions
are intended to be called by library code. Several LWG members are
concerned that valarray appears to require argument-dependent lookup,
but that the wording may not be clear enough to fall under
"unless explicitly described otherwise".]
[Curaçao: An LWG-subgroup spent an afternoon working on issues 225, 226, and 229. Their conclusion was that the issues should be separated into an LWG portion (Howard's paper, N1387=02-0045), and a EWG portion (Dave will write a proposal). The LWG and EWG had (separate) discussions of this plan the next day. This paper resolves issues 225 and 226. In light of that resolution, the proposed resolution for the current issue makes sense.]