﻿<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0108)file://C:\Documents%20and%20Settings\jward4\Local%20Settings\Temporary%20Internet%20Files\OLK462F\n1691.html -->
<?xml version="1.0" encoding="utf-8" ?><HTML lang=en xml:lang="en" 
xmlns="http://www.w3.org/1999/xhtml"><HEAD><TITLE>Explicit Namespaces</TITLE>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.2800.1400" name=GENERATOR>
<META content="7 Sept 2004" name=date>
<META content="Boost Consulting" name=organization>
<STYLE type=text/css>.first {
	MARGIN-TOP: 0px
}
.last {
	MARGIN-BOTTOM: 0px
}
A.toc-backref {
	COLOR: black; TEXT-DECORATION: none
}
BLOCKQUOTE.epigraph {
	MARGIN: 2em 5em
}
DD {
	MARGIN-BOTTOM: 0.5em
}
DIV.abstract {
	MARGIN: 2em 5em
}
DIV.abstract P.topic-title {
	FONT-WEIGHT: bold; TEXT-ALIGN: center
}
DIV.attention {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.caution {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.danger {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.error {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.hint {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.important {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.note {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.tip {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.warning {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.admonition {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; MARGIN: 2em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.attention P.admonition-title {
	FONT-WEIGHT: bold; COLOR: red; FONT-FAMILY: sans-serif
}
DIV.caution P.admonition-title {
	FONT-WEIGHT: bold; COLOR: red; FONT-FAMILY: sans-serif
}
DIV.danger P.admonition-title {
	FONT-WEIGHT: bold; COLOR: red; FONT-FAMILY: sans-serif
}
DIV.error P.admonition-title {
	FONT-WEIGHT: bold; COLOR: red; FONT-FAMILY: sans-serif
}
DIV.warning P.admonition-title {
	FONT-WEIGHT: bold; COLOR: red; FONT-FAMILY: sans-serif
}
DIV.hint P.admonition-title {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
DIV.important P.admonition-title {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
DIV.note P.admonition-title {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
DIV.tip P.admonition-title {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
DIV.admonition P.admonition-title {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
DIV.dedication {
	MARGIN: 2em 5em; FONT-STYLE: italic; TEXT-ALIGN: center
}
DIV.dedication P.topic-title {
	FONT-WEIGHT: bold; FONT-STYLE: normal
}
DIV.figure {
	MARGIN-LEFT: 2em
}
DIV.footer {
	FONT-SIZE: smaller
}
DIV.header {
	FONT-SIZE: smaller
}
DIV.sidebar {
	CLEAR: right; BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; FLOAT: right; PADDING-BOTTOM: 0em; MARGIN-LEFT: 1em; BORDER-LEFT: outset; WIDTH: 40%; PADDING-TOP: 0em; BORDER-BOTTOM: outset; BACKGROUND-COLOR: #ffffee
}
DIV.sidebar P.rubric {
	FONT-SIZE: medium; FONT-FAMILY: sans-serif
}
DIV.system-messages {
	MARGIN: 5em
}
DIV.system-messages H1 {
	COLOR: red
}
DIV.system-message {
	BORDER-RIGHT: outset; PADDING-RIGHT: 1em; BORDER-TOP: outset; PADDING-LEFT: 1em; PADDING-BOTTOM: 1em; BORDER-LEFT: outset; PADDING-TOP: 1em; BORDER-BOTTOM: outset
}
DIV.system-message P.system-message-title {
	FONT-WEIGHT: bold; COLOR: red
}
DIV.topic {
	MARGIN: 2em
}
H1.title {
	TEXT-ALIGN: center
}
H2.subtitle {
	TEXT-ALIGN: center
}
HR {
	WIDTH: 75%
}
OL.simple {
	MARGIN-BOTTOM: 1em
}
UL.simple {
	MARGIN-BOTTOM: 1em
}
OL.arabic {
	LIST-STYLE-TYPE: decimal
}
OL.loweralpha {
	LIST-STYLE-TYPE: lower-alpha
}
OL.upperalpha {
	LIST-STYLE-TYPE: upper-alpha
}
OL.lowerroman {
	LIST-STYLE-TYPE: lower-roman
}
OL.upperroman {
	LIST-STYLE-TYPE: upper-roman
}
P.attribution {
	MARGIN-LEFT: 50%; TEXT-ALIGN: right
}
P.caption {
	FONT-STYLE: italic
}
P.credits {
	FONT-SIZE: smaller; FONT-STYLE: italic
}
P.label {
	WHITE-SPACE: nowrap
}
P.rubric {
	FONT-WEIGHT: bold; FONT-SIZE: larger; COLOR: maroon; TEXT-ALIGN: center
}
P.sidebar-title {
	FONT-WEIGHT: bold; FONT-SIZE: larger; FONT-FAMILY: sans-serif
}
P.sidebar-subtitle {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
P.topic-title {
	FONT-WEIGHT: bold
}
PRE.address {
	MARGIN-TOP: 0px; FONT-SIZE: 100%; MARGIN-BOTTOM: 0px; FONT-FAMILY: serif
}
PRE.line-block {
	FONT-SIZE: 100%; FONT-FAMILY: serif
}
PRE.literal-block {
	MARGIN-LEFT: 2em; MARGIN-RIGHT: 2em; BACKGROUND-COLOR: #eeeeee
}
PRE.doctest-block {
	MARGIN-LEFT: 2em; MARGIN-RIGHT: 2em; BACKGROUND-COLOR: #eeeeee
}
SPAN.classifier {
	FONT-STYLE: oblique; FONT-FAMILY: sans-serif
}
SPAN.classifier-delimiter {
	FONT-WEIGHT: bold; FONT-FAMILY: sans-serif
}
SPAN.interpreted {
	FONT-FAMILY: sans-serif
}
SPAN.option {
	WHITE-SPACE: nowrap
}
SPAN.option-argument {
	FONT-STYLE: italic
}
SPAN.pre {
	WHITE-SPACE: pre
}
SPAN.problematic {
	COLOR: red
}
TABLE {
	MARGIN-TOP: 0.5em; MARGIN-BOTTOM: 0.5em
}
TABLE.citation {
	PADDING-LEFT: 0.5ex; BORDER-LEFT: gray thin solid
}
TABLE.docinfo {
	MARGIN: 2em 4em
}
TABLE.footnote {
	PADDING-LEFT: 0.5ex; BORDER-LEFT: black thin solid
}
DT {
	FONT-WEIGHT: bold
}
TD {
	PADDING-RIGHT: 0.5em; PADDING-LEFT: 0.5em; VERTICAL-ALIGN: top
}
TH {
	PADDING-RIGHT: 0.5em; PADDING-LEFT: 0.5em; VERTICAL-ALIGN: top
}
TH.docinfo-name {
	FONT-WEIGHT: bold; WHITE-SPACE: nowrap; TEXT-ALIGN: left
}
TH.field-name {
	FONT-WEIGHT: bold; WHITE-SPACE: nowrap; TEXT-ALIGN: left
}
H1 TT {
	FONT-SIZE: 100%
}
H2 TT {
	FONT-SIZE: 100%
}
H3 TT {
	FONT-SIZE: 100%
}
H4 TT {
	FONT-SIZE: 100%
}
H5 TT {
	FONT-SIZE: 100%
}
H6 TT {
	FONT-SIZE: 100%
}
TT {
	BACKGROUND-COLOR: #eeeeee
}
UL.auto-toc {
	LIST-STYLE-TYPE: none
}
</STYLE>
</HEAD>
<BODY>
<H1 class=title>Explicit Namespaces</H1>
<TABLE class=docinfo rules=none frame=void>
  <COLGROUP>
  <COL class=docinfo-name>
  <COL class=docinfo-content>
  <TBODY vAlign=top>
  <TR class=field>
    <TH class=docinfo-name>Number:</TH>
    <TD class=field-body>N1691=04-0131</TD></TR>
  <TR>
    <TH class=docinfo-name>Date:</TH>
    <TD>7 Sept 2004</TD></TR>
  <TR class=field>
    <TH class=docinfo-name>Project:</TH>
    <TD class=field-body>Programming Language C++</TD></TR>
  <TR class=field>
    <TH class=docinfo-name>Reply-to:</TH>
    <TD class=field-body>David Abrahams &lt;<A class=reference 
      href="mailto:dave@boost-consulting.com">dave@boost-consulting.com</A>&gt;</TD></TR>
  <TR>
    <TH class=docinfo-name>Organization:</TH>
    <TD><A class="first last reference" 
      href="http://www.boost-consulting.com/">Boost 
Consulting</A></TD></TR></TBODY></TABLE>
<DIV class=document id=explicit-namespaces>
<DIV class="contents topic" id=index>
<P class="topic-title first"><A name=index>Index</A></P>
<UL class="auto-toc simple">
  <LI><A class=reference id=id8 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#executive-summary" 
  name=id8>1???Executive Summary</A> 
  <LI><A class=reference id=id9 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#background" 
  name=id9>2???Background</A>
  <UL class=auto-toc>
    <LI><A class=reference id=id10 
    href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#problem-1-unintended-overloading" 
    name=id10>2.1???Problem 1: Unintended Overloading</A> 
    <LI><A class=reference id=id11 
    href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#problem-2-name-reservation" 
    name=id11>2.2???Problem 2: Name Reservation</A> 
    <LI><A class=reference id=id12 
    href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#summary-of-issues" 
    name=id12>2.3???Summary of Issues</A> </LI></UL>
  <LI><A class=reference id=id13 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#a-solution" 
  name=id13>3???A Solution</A> 
  <LI><A class=reference id=id14 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#implications-for-namespace-std-and-other-libraries" 
  name=id14>4???Implications for Namespace <TT class=literal><SPAN 
  class=pre>std</SPAN></TT> and Other Libraries</A> 
  <LI><A class=reference id=id15 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#conclusion" 
  name=id15>5???Conclusion</A> </LI></UL></DIV>
<DIV class=section id=executive-summary>
<H1><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id8" 
name=executive-summary>1???Executive Summary</A></H1>
<P>This proposal:</P>
<UL class=simple>
  <LI>Eliminates unpredictable and unintended overloading due to 
  argument-dependent lookup (ADL) 
  <LI>Provides a way to be explicit about where ADL should apply 
  <LI>Provides a clean way for generic libraries to supply 
  points-of-customization (e.g. <TT class=literal><SPAN 
  class=pre>swap</SPAN></TT>) for user-defined types 
  <LI>Eliminates the problem of unintended "name reservation" when overloading 
  is used for customization (see <A class=reference 
  href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1296.asc">N1296</A>) 

  <LI>Allows clients to be explicit about which algorithm they mean to customize 
  via overloading 
  <LI>Reduces the "syntactic weight" of client-supplied template 
  specializations. 
  <LI>And describes how existing code (and even the standard library) can be 
  migrated to use the new facility. </LI></UL></DIV>
<DIV class=section id=background>
<H1><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id9" 
name=background>2???Background</A></H1>
<P>Before the introduction of namespaces to C++, it was a common practice to 
apply "prefixes" to all names with external linkage, in an attempt to avoid 
unpredictable collisions between code in applications and the libraries they 
linked to. As long as the prefixes were reasonably long, this practice worked 
reasonably well, and is still being used effecively for preprocessor macros. The 
major disadvantage of prefixes is aesthetic: there is no way to avoid using the 
prefix within user code or even within the context of a library's own 
definition.</P>
<P>Namespaces gave users and library writers a way to partition the set of all 
names so that the use of qualification (the namespace mechanism's replacement 
for prefixing) could be avoided for names defined in local or enclosing 
contexts. Via <EM>using-declaration</EM>s and <EM>using-directive</EM>s, we also 
provided a mechanism for using names from other namespaces <EM>without</EM> 
qualification, thus combining convenience with protection.</P>
<P>The system described so far is intuitive, convenient, and safe: an entity in 
the local namespace or in any enclosing namespace can be accessed without 
qualification, and entities in other namespaces can either be explicitly 
qualified or brought into the local scope with a using declaration for 
convenience. Many new programmers expect namespaces to work exactly this 
way.</P>
<DIV class=section id=problem-1-unintended-overloading>
<H2><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id10" 
name=problem-1-unintended-overloading>2.1???Problem 1: Unintended 
Overloading</A></H2>
<P>Unfortunately, when argument-dependent lookup is added to the mix, namespaces 
fail to deliver the convenience and protection they seemed to promise even for 
ordinary function calls. For example:</P>
<DIV class=topic>
<P class="topic-title first">Example 1</P><A class=target id=example-1 
name=example-1></A><PRE class=literal-block>// main.cpp:
#include &lt;vector&gt;

namespace user
{
   typedef std::vector&lt;Customer*&gt; index;

   // copy an index, selecting deep or shallow copy for Customers
   void copy(index const&amp;, index&amp;, bool deep);

   void g(index const&amp; x)
   {
      copy(x, x, false);
   }
}
</PRE></DIV>
<P>In <A class=reference 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#example-1">Example 
1</A>, the author of <TT class=literal><SPAN class=pre>g</SPAN></TT> intended to 
call <TT class=literal><SPAN class=pre>user::copy</SPAN></TT>, but in most C++ 
implementations <TT class=literal><SPAN class=pre>std::copy</SPAN></TT> is found 
and will be a better match. Luckily, it will cause a error when <TT 
class=literal><SPAN class=pre>std::copy</SPAN></TT> is instantiated, but that 
may not happen until link time, depending on the instantiation model. 
Furthermore, it's easy to come up with examples that silently choose the wrong 
function without issuing a single diagnostic:</P>
<DIV class=topic>
<P class="topic-title first">Example 2</P><A class=target id=example-2 
name=example-2></A><PRE class=literal-block>#include &lt;tr1/shared_ptr&gt;
#include &lt;tr1/tuple&gt;

namespace communications
{
    class Channel;
}

namespace user
{
   typedef tr1::shared_ptr&lt;communications::Channel&gt; pipe;

   // Connect p2 to the output of p1
   tie(pipe const&amp; p1, pipe&amp; p2);

   void g(pipe p1, pipe p2)
   {
      tie(p1, p2);  // calls tr1::tie
   }
}
</PRE></DIV>
<P>The upshot is this highly counter-intuitive fact:</P>
<DIV class="admonition-fact admonition">
<P class="admonition-title first">Fact</P>
<P>When calling functions in <EM>her own namespace</EM>, a conscientious 
programmer must disable ADL by using <EM>qualified calls</EM>. <A 
class=footnote-reference id=id1 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#parens" 
name=id1><SUP>1</SUP></A></P></DIV>
<P>Aside from the fact that qualification adds a great deal of syntactic weight 
for something as natural and trivial as calling a function in an author's own 
namespace, the problem here is that unqualified calls to nearby functions are 
what we all write "naturally." It's what people learn from textbooks and from 
other languages. The vigilance required in order to write even the most 
straightforward code in a way that's impervious to the effects of ADL is more 
than we should ask any user to exercise.</P></DIV>
<DIV class=section id=problem-2-name-reservation>
<H2><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id11" 
name=problem-2-name-reservation>2.2???Problem 2: Name Reservation</A></H2>
<DIV class="admonition-definition admonition">
<P class="admonition-title first">Definition</P>
<P>A <STRONG>point of customization</STRONG> is a procedure (like <TT 
class=literal><SPAN class=pre>swap</SPAN></TT>) whose implementation might be 
supplied or refined by clients for specific types, and that is used by a library 
component (like <TT class=literal><SPAN class=pre>sort</SPAN></TT>).</P></DIV>
<P>Library authors currently have three options (described in <A class=reference 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1296.asc">N1296</A>) 
when providing a "point of customization" for client types. <A 
class=footnote-reference id=id2 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#fourth" 
name=id2><SUP>2</SUP></A> Let's review:</P>
<OL class=arabic>
  <LI>
  <P class=first>Invite clients to write a function that implements the 
  procedure in the same namespace as their class:</P><PRE class=literal-block>namespace my_namespace
{
  class my_class;
  void swap(my_class&amp;, my_class&amp;);
  ...
}
</PRE>
  <P>Call the function without qualification and let ADL find it:</P><PRE class=literal-block>swap(x, y);
</PRE>
  <LI>
  <P class=first>Invite clients to specialize a library function:</P><PRE class=literal-block>namespace my_namespace
{
  class my_class;
  ...
}

namespace std
{
  template &lt;&gt; void swap(
      my_namespace::my_class&amp;, my_namespace::my_class&amp;
  ) { ... }
}
</PRE></LI></OL>
<BLOCKQUOTE>
  <P>Call the function with qualification:</P><PRE class=literal-block>std::swap(x, y);
</PRE></BLOCKQUOTE>
<OL class=arabic start=3>
  <LI>
  <P class=first>Invite clients to (explicitly or partially) specialize a 
  library class template that has a static member function implementing the 
  procedure:</P><PRE class=literal-block>namespace my_namespace
{
  template &lt;class T&gt; class my_class_template;
  ...
}

namespace std
{
  template &lt;class T&gt; 
  struct swap_impl&lt;my_namespace::my_class_template&lt;T&gt; &gt;
  {
      void swap(
          my_namespace::my_class_template&lt;T&gt;&amp;
        , my_namespace::my_class_template&lt;T&gt;&amp;
  };
}
</PRE></LI></OL>
<BLOCKQUOTE>
  <P>Call the function with qualification through the class:</P><PRE class=literal-block>std::swap_impl&lt;T&gt;::swap(x, y);
</PRE></BLOCKQUOTE>
<P>Because there is no partial specialization of function templates, option 2 
can't be used to supply a customization that applies to <EM>all</EM> 
specializations of a given class template, which gives rise to option 3. Of the 
last two, option 3 is the only one that generalizes, but in complexity and 
syntactic weight, it is overwhelming. Adding the ability to partially specialize 
function templates would improve things a bit, but the syntactic weight of 
customization would still be substantial, and existing operations implemented as 
ordinary functions such as <TT class=literal><SPAN 
class=pre>std::abs</SPAN></TT> can't be customized this way (see <A 
class=reference 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1296.asc">N1296</A>).</P>
<P>Option 1 is the simplest and most natural for both library authors and for 
clients, but there's a problem: two libraries could advertise identically named 
points of customization with different semantics. Under option 1, libraries must 
declare explicitly which names are being used without qualification by which 
functions; users must take care to avoid defining these names in their own 
namespaces except where the intention is to customize a given library. If two 
library implementors happen to choose the same function name as a 
point-of-customization with different semantics, the result is at best 
confusing: the user may need to create two overloads of the same name in his own 
namespace with different semantics. Since the name is the same, it's quite 
likely that the semantics will be similar, but not identical. In the worst case, 
the functions have identical signatures, and the libraries simply refuse to 
interoperate in the user's application. A corollary problem is that when 
providing a customization with a given name, there's no way for a client to 
indicate in code which library's meaning of that name she is 
implementing.</P></DIV>
<DIV class=section id=summary-of-issues>
<H2><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id12" 
name=summary-of-issues>2.3???Summary of Issues</A></H2>
<BLOCKQUOTE class=epigraph>
  <P><EM>The various type checking and access control rules exist to allow a 
  class provider to state clearly what is expected from users, to protect 
  against accidents.</EM></P>
  <P class=attribution>—Bjarne Stroustrup, <EM>The Design and Evolution of 
  C++</EM>, section 4.3</P></BLOCKQUOTE>
<P>The irony here is hard to escape: the sort of name clashes we've seen are 
<EM>exactly</EM> what namespaces are supposed to help us avoid. In fact, 
compared with the situation before namespaces, we seem to have added new 
opportunities for accidents. In a world of prefixed names, a library writer's 
own test code would be unlikely to compile correctly if a prefix were ommitted, 
so once the choice to use prefixes is made, the compiler enforces qualification. 
Today, both library authors and users must exercise extreme vigilance to be sure 
that, except where ADL is explicitly intended, all calls whose arguments could 
come from any other namespace are qualified. Since unqualified calls are 
perfectly legal, programmers get no support from the compiler in this effort. 
Since they are perfectly easy, and will unintended ADL will pass unnoticed 
through all but the most sadistic tests, there is little incentive other than 
good conscience to add qualification. These errors are the sort that show up 
only after libraries are deployed, and when user code is being maintained by 
someone other than its original author.</P></DIV></DIV>
<DIV class=section id=a-solution>
<H1><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id13" 
name=a-solution>3???A Solution</A></H1>
<P>The solution I'll propose here centers around a different kind of namespace 
with new lookup rules, on the assumption that breaking backward compatibility of 
existing namespaces is unacceptable. I would dearly love to find a solution that 
didn't involve major language changes, but I don't see any alternative that 
allows the compiler to help library authors prevent unintended 
argument-dependent lookups.</P>
<P>The new entity is called an "explicit namespace", and is declared by 
preceding the namespace keyword with <TT class=literal><SPAN 
class=pre>explicit</SPAN></TT>, as follows:</P><PRE class=literal-block>explicit namespace new_std
{
    // declarations and definitions
}
</PRE>
<P>The lookup rules in an explicit namespace differ from those in an old-style 
namespace as follows:</P>
<DL>
  <DT>I. 
  <DD>By default, argument-dependent lookup does not take effect for arbitrary 
  unqualified calls made within definitions in an explicit namespace. 
  <DT>II. 
  <DD>
  <P class=first>Argument-dependent lookup can be enabled for specific names 
  through the use of an <EM>unqualified using-declaration</EM>:</P><PRE class=literal-block>explicit namespace new_std::
{
   using swap; // enables argument-dependent lookup of 
               // "swap" from within new_std

   template &lt;class Iterator&gt;
   void sort(Iterator start, Iterator finish)
   {
      ...
      swap(*a, *b); // uses argument-dependent lookup
      ...
   }
}
</PRE>
  <P>The <EM>unqualified using-declaration</EM> can also be used within a 
  function template definition, further limiting the scope of its effect:</P><PRE class=literal-block>explicit namespace new_std
{
   template &lt;class Iterator&gt;
   void sort(Iterator start, Iterator finish)
   {
      using swap; // allows argument-dependent lookup of "swap" from
                  // within new_std::sort

      ...
      swap(*a, *b); // uses argument-dependent lookup
      ...
   }
}
</PRE><!-- * --></DD></DL><A class=target id=iii name=iii></A>
<DL>
  <DT>III. 
  <DD>
  <P class=first>In templates in explicit namespaces, functions calls that do 
  not use argument-dependent lookup but whose arguments are dependent types are 
  bound to actual overloads at instantiation time. However, such calls must 
  match <EM>some</EM> declaration in name and arity at template definition time: 
  <A class=footnote-reference id=id3 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#stricter" 
  name=id3><SUP>3</SUP></A></P><PRE class=literal-block>explicit namespace new_std
{
   template &lt;class Iterator&gt;
   void iter_swap(Iterator x, Iterator y)
   {
      swap(*x,*y); // error: no swap defined in new_std or ::
   }

   template &lt;class T&gt; void swap(T&amp;, T&amp;);

   template &lt;class Iterator&gt;
   void sort(Iterator start, Iterator finish)
   {
      ...
      swap(*a, *b); // OK: the swap above could match
      ...
   }
}
</PRE>
  <P>Binding at instantiation time ensures that overloading in the algorithm's 
  namespace is a viable means of customization, with no dependency on <TT 
  class=literal><SPAN class=pre>#include</SPAN></TT> order.</P>
  <P>Overloading in the algorithm's namespace solves the library 
  interoperability problems implied by asking users to provide overloads for 
  each library in her own namespace.</P>
  <P class=last>Requiring a match at definition time allows template definitions 
  to be syntax-checked before instantiation. Since nobody will be using 
  argument-dependent lookup by mistake in an explicit namespace, it should be 
  possible in practice to check syntax much <EM>more</EM> thoroughly in an 
  explicit namespace than in an ordinary one.</P>
  <DT>IV. 
  <DD>
  <P class=first>To make generic library customization convenient, functions and 
  templates previously declared in other namespaces can be overloaded and 
  specialized "remotely", without opening the other namespace. This capability 
  applies to both ordinary and explicit namespaces:</P><PRE class=literal-block>#include &lt;complex&gt;
#include &lt;algorithm&gt;

namespace user
{
   class fixedpoint
   {
      ...
   };

   // Specialize std::complex
   template &lt;&gt; class std::complex&lt;fixedpoint&gt;
   {
     ...
   };

   void std::swap(fixedpoint&amp;, fixedpoint&amp;);   // OK

   // illegal by current rules, and also under new rules:
   // vector not yet declared in std::
   template &lt;&gt; class std::vector&lt;fixedpoint&gt;;

   // illegal by new rule: iter_swap() not yet declared in std::
   void std::iter_swap(fixedpoint*, fixedpoint*);
}
</PRE>
  <P>For function overloads, a declaration of a function with the same number of 
  arguments in the target namespace must already be visible: <A 
  class=footnote-reference id=id4 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#enable-if" 
  name=id4><SUP>4</SUP></A></P><PRE class=literal-block>#include &lt;algorithm&gt;
namespace user
{
   void std::swap(fixedpoint&amp;, fixedpoint&amp;, int); // illegal
}
</PRE>
  <P>The same technique applies to the "Barton &amp; Nackman trick", allowing it 
  to be used to provide customizations for explicit namespaces:</P><PRE class=literal-block>namespace user
{
   class fixedpoint
   {
      ...
      friend fixedpoint newstd::math::sin(fixedpoint)
      {
         ...
      }
   };
}
</PRE>
  <P class=last>Friend functions defined in this way would not be subject to the 
  usual restrictions that prevent them from being found other than through 
  argument-dependent lookup (see Sections 3.4.1 paragraph 1 and 11.4 paragraph 9 
  of the standard).</P>
  <DT>V. 
  <DD>
  <P class=first>Operators within an explicit namespace should be treated the 
  same way as any other function. Argument-dependent lookup could be explicitly 
  enabled through the use of <EM>unqualified using-declaration</EM>s:</P><PRE class=literal-block>template &lt;class T&gt;
T square(T x)
{
   using operator*;
   return x * x;
}
</PRE>
  <P>Those seeking to conveniently enable argument-dependent lookups for all 
  operators within an explicit namespace could easily create a header file that 
  does so:</P><PRE class="last literal-block">namespace mymath::
{
   #include "using_ops.hpp"
}
</PRE>
  <DT>VI. 
  <DD>Partial specialization of function templates would be allowed per <A 
  class=reference 
  href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2001/n1295.asc">N1295</A>. 
  It's worth discussing whether element <A class=reference 
  href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#iii">III</A> 
  of this proposal is needed once we have partial specialization of function 
  templates. </DD></DL></DIV>
<DIV class=section id=implications-for-namespace-std-and-other-libraries>
<H1><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id14" 
name=implications-for-namespace-std-and-other-libraries>4???Implications for 
Namespace <TT class=literal><SPAN class=pre>std</SPAN></TT> and Other 
Libraries</A></H1>
<P><A class=reference 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1523.htm">N1523</A> 
describes the WP status resolution to LWG <A class=reference 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#225">225</A>, 
<A class=reference 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#226">226</A>, 
and <A class=reference 
href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#229">229</A>. 
It allows algorithms in namespace <TT class=literal><SPAN 
class=pre>std</SPAN></TT> to call other selected algorithms, most notably <TT 
class=literal><SPAN class=pre>swap</SPAN></TT>, without qualification so they 
can be found via argument-dependent lookup. If we continue to follow that 
course, implications for <TT class=literal><SPAN class=pre>std</SPAN></TT> are 
minimal. Authors of generic libraries in other namespaces must always add a 
<EM>using-declaration</EM> to bring the generalized algorithm into scope at the 
point of use, but this is status quo:</P><PRE class=literal-block>namespace lib1
{
  template&lt;class Iterator&gt;
  void lib1_permutation(Iterator start, Iterator finish)
  {
     ...
     using std::swap; // so we can swap built-in types
     swap(x, y);
     ...
  }
}
</PRE>
<P>It is worth noting that when a generalized version of an algorithm exists, as 
in the case of swap, that algorithm is effectively associated with a namespace. 
The <EM>using-declaration</EM> becomes a clumsy form of qualification that 
indicates the algorithm's home.</P>
<P>If we choose to follow the course of using argument-dependent lookup to allow 
customization in namespace <TT class=literal><SPAN class=pre>std</SPAN></TT>, 
this proposal at least allows implementors to migrate the standard library to a 
safer explicit namespace without breaking backward compatibility. The list of 
names and call contexts where argument-dependent lookup takes effect could 
simply be encoded in <EM>unqualified using-declaration</EM>s.</P>
<P>If we choose not to allow further argument-dependent lookup in namespace <TT 
class=literal><SPAN class=pre>std</SPAN></TT>, it could still become an explicit 
namespace, and implementations could drop their qualification of calls to 
algorithms like <TT class=literal><SPAN class=pre>copy</SPAN></TT>. We could 
grant permission to create overloads in <TT class=literal><SPAN 
class=pre>std::</SPAN></TT> consistent with the standard versions of the same 
function, allowing users to customize exactly the intended standard library 
algorithm. Other libraries would call standard algorithms with qualification as 
usual, and would not need to rely on argument-dependent lookup to resolve the 
calls.</P></DIV>
<DIV class=section id=conclusion>
<H1><A class=toc-backref 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id15" 
name=conclusion>5???Conclusion</A></H1>
<P>The future of C++ lies in its power to make great libraries, so the issues of 
library interoperability, customization, and robustness must be taken seriously. 
If we compare the C++ standard library with the sprawling libraries of languages 
like Java or Python, it's easy to see that the potential to increase the number 
of namespaces competing for an unqualified name is enormous. This proposal puts 
the compiler's static checking at the service of library authors and allows 
users to conveniently and precisely express the notion of algorithm 
customization.</P>
<TABLE class=footnote id=parens rules=none frame=void>
  <COLGROUP>
  <COL class=label>
  <COL></COLGROUP>
  <TBODY vAlign=top>
  <TR>
    <TD class=label><A class=fn-backref 
      href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id1" 
      name=parens>[1]</A></TD>
    <TD>
      <P>You can also disable ADL by parenthesizing the function name:</P><PRE class=literal-block>(copy)(x, x, false)
</PRE>
      <P>but in my opinion this is really against the syntactic spirit of 
      C/C++.</P></TD></TR></TBODY></TABLE>
<TABLE class=footnote id=fourth rules=none frame=void>
  <COLGROUP>
  <COL class=label>
  <COL></COLGROUP>
  <TBODY vAlign=top>
  <TR>
    <TD class=label><A class=fn-backref 
      href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id2" 
      name=fourth>[2]</A></TD>
    <TD>Template authors might consider inviting library clients to supply 
      overloads in the library's own namespace so that the functions can be 
      called with qualification, but because qualified calls are bound at the 
      point of definition, that approach is subject to dangerous <TT 
      class=literal><SPAN class=pre>#include</SPAN></TT> order dependencies, or, 
      with exported templates, is completely unworkable.</TD></TR></TBODY></TABLE>
<TABLE class=footnote id=stricter rules=none frame=void>
  <COLGROUP>
  <COL class=label>
  <COL></COLGROUP>
  <TBODY vAlign=top>
  <TR>
    <TD class=label><A class=fn-backref 
      href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id3" 
      name=stricter>[3]</A></TD>
    <TD>Probably stricter checks for potential matches are 
  possible.</TD></TR></TBODY></TABLE>
<TABLE class=footnote id=enable-if rules=none frame=void>
  <COLGROUP>
  <COL class=label>
  <COL></COLGROUP>
  <TBODY vAlign=top>
  <TR>
    <TD class=label><A class=fn-backref 
      href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.html#id4" 
      name=enable-if>[4]</A></TD>
    <TD>I have some concerns that this rule might rule out some useful 
      applications of SFINAE.</TD></TR></TBODY></TABLE></DIV></DIV>
<HR class=footer>

<DIV class=footer><A class=reference 
href="file:///C:/Documents%20and%20Settings/jward4/Local%20Settings/Temporary%20Internet%20Files/OLK462F/n1691.rst">View 
document source</A>. Generated on: 2004-09-11 00:19 UTC. Generated by <A 
class=reference href="http://docutils.sourceforge.net/">Docutils</A> from <A 
class=reference 
href="http://docutils.sourceforge.net/rst.html">reStructuredText</A> source. 
</DIV></BODY></HTML>
