<html>

<head>
  <meta name="description" content="Proposal for C++ Standard">
  <meta name="keywords" content="C++,cplusplus,wg21">
  <meta name="author" content="Alisdair Meredith">

  <title>Reserve a New Library Namespace Future Standardization</title>

  <style type="text/css">
    ins {background-color:#A0FFA0}
    del {background-color:#FFA0A0}
    p {text-align:justify}
    li {text-align:justify}
    blockquote.note
    {
      background-color:#E0E0E0;
      padding-left: 15px;
      padding-right: 15px;
      padding-top: 1px;
      padding-bottom: 1px;
    }
  </style>
</head>

<body>
<table>
<tr>
  <td align="left">Doc. no.</td>
  <td align="left">P0180R0</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2016-02-10</td>
</tr>
<tr>
  <td align="left">Project:</td>
  <td align="left">Programming Language C++</td>
</tr>
<tr>
  <td align="left">Audience:</td>
  <td align="left">Library Evolution Working Group</td>
</tr>
<tr>
  <td align="left">Reply to:</td>
  <td align="left">Alisdair Meredith &lt;<a href="mailto:ameredith1@bloomberg.net">ameredith1@bloomberg.net</a>&gt;</td>
</tr>
</table>

<h1>Reserve a New Library Namespace Future Standardization</h1>

<h2>Table of Contents</h2>
<ol>
<li><a href="#0.0">Revision History</a></li>
  <ul>
  <li><a href="#0.1">Revision 0</a></li>
  </ul>
<li><a href="#1.0">Introduction</a></li>
<li><a href="#2.0">Why We Need A New Namespace</a></li>
<li><a href="#3.0">Propose Solution</a></li>
  <ul>
  <li><a href="#3.1">Is the problem urgent?</a></li>
  <li><a href="#3.2">Choosing a namespace</a></li>
  <li><a href="#3.3">Restrictions using a future namespace</a></li>
  </ul>
<li><a href="#4.0">Formal Wording</a></li>
<li><a href="#5.0">References</a></li>
</ol>


<h2><a name="0.0">Revision History</a></h2>

<h3><a name="0.1">Revision 0</a></h3>
<p>
Original version of the paper for the 2016 pre-Jacksonville mailing.
</p>


<h2><a name="1.0">Introduction</a></h2>
<p>
Over the last few meetings, there have been informal suggestions that we should
consider larger-scale changes for a revised standard library at some point in
the future, and that time is closing.  This paper suggests that we should
reserve a namespace for that potential library now, so give the best chance
that name will be free for use in standardization when needed.
</p>


<h2><a name="2.0">Why We Need A New Namespace</a></h2>
<p>
As the number of changes to the core language accumulate, and a better
understanding of how modern C++ libraries should be written to take work well
with modern idioms grows, there are increasing demands to make more significant
changes or revisions to the current standard library.  At some point, maybe as
early as C++20, we may want to have a library that clearly breaks backwards
compatibility with the standard libraries that have gone before.  Key pending
features that might inspire more radical changes include the addition of
concepts, concepts, implicit comparison operators (with a meaning different to
that of the current library), unified function call syntax changing the
relationship between member and free functions, and a desire to take advantage
of more recent developments in the standard library, such as adopting generic
(<i>transparent</i>) functors as the default library comparators.  The Ranges
TS gives a good insight into how a future library might be more capable, yet
simpler to implement at the same time, if we can pick the appropriate
abstractions.  There are also several library issues that keep resurfacing in
the concurrency clauses where it seems clear that we might have chosen a
different behavior with but a little more feedback, but that are incredibly
hard to change within the current standard library.
</p>

<p>
C++11 introduced the idea of <tt>inline</tt> namespaces to help solve the
versioning problem.  The key benefit of inline namespaces is that they allow a
libray vendor to preserve a stable ABI for old libraries, that existing code
can continue to link against, while allowing new code to use the most recent
version of the library, with an updated API, and potentially
source-incompatible APIs.
</p>

<p>
The problem with relying on inline namespaces to solve the standard library
versioning problem is that they did not exist when most of the current standard
library implementations were created, so they are not in a position to use
inline namespaces to preserve compatibility for their current implementations.
If we were starting a new library, that solution would be baked into the
initial deployment, and the problem of future compatibility could then be
solved.
</p>


<h2><a name="3.0">Proposed Solution</a></h2>
<p>
This paper proposes reserving a new namespace for future standardization, while
not yet putting anything in there.  This is similar to reserving namespace
<tt>posix</tt> for C++11,
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2667">N2667</a>.
</p>
<p>
The namespace should be reserved now so that any existing code currently using
that namespace has notice and time to migrate, before there is a real problem
interfering with the standard.  Likewise, authors of new code are on notice
that this namespace is reserved.  The longer we wait to reserve such a
namespace, the fewer reasonable names will be available.
</p>
<p>
Using a whole new namespace for a future library allows for an smoother transition
for users, who can migrate code from one library to the other at a pace of their
own choosing, while allowing the Library groups to be more aggressive in their
approach to a <i>mostly</i> source compatible revised library.
</p>

<h3><a name="3.1">Is the problem urgent?</a></h3>
<p>
It is clear (I think) that we do not need a new namespace for the anticipated
C++17 standard library.  However, the longer we take to reserve a library for
our future needs, the harder it will be to choose a useful, practical, namespace
without seriously disrupting some of our community.  It is important to put the
C++ community at large on notice that some part of the universal naming space
should be considered reserved for future standards, and C++17 is our next, best
shipping vehicle to make that happen.  With that said, we still have several
meetings before shipping a CD to research which specific name might be most
appropriate and least disruptive - the main urgency is to agree whether or not
this direction is desirable at all.
</p>

<h3><a name="3.2">Choosing a namespace</a></h3>
<p>
The ideal namespace would be short, pronounceable, and meaningful.  As such, it
is most likely taken by a variety of other organizations.  Nevertheless, this
paper will proceed with <tt>std2</tt> as a simple placeholder for a name that
should be chosen, with some careful research, by the Library Evolution Working
Group.
</p>

<h3><a name="3.3">Restrictions using a future namespace</a></h3>
<p>
While picking a new namespace may solve a wide variety of migration issues for
the standard library, there will remain a few key classes and APIs that cannot
migrate to a new namespace.  These are the classes designed for interaction
with the core language, and are mostly specified in clause 18.  The most
obvious cases are the low level exception hierarchy, <tt>exception</tt>,
<tt>bad_alloc</tt>, <tt>bad_array_new_length</tt>, <tt>bad_cast</tt>,
<tt>bad_exception</tt>, and <tt>bad_typeid</tt>.  Note that exceptions derived
from <tt>logic_error</tt> or <tt>runtime_error</tt> are safely in the library
domain, and not referenced by the core language.  Additional library classes
that interact directly with the compiler include <tt>exception_ptr</tt>,
<tt>initializer_list</tt>, and <tt>typeinfo</tt>, in addition to registration
facilities like the new and terminate handlers.
</p>


<h3><a name="4.0">Formal Wording</a></h3>
<p>
Insert the following new subsection into clause 17:
</p>

<blockquote>

<h4>17.6.4.2.3 Namespace iso [namespace.iso]</h4>
<p>
<ol>
<li>
The behavior of a C++ program is undefined if it adds declarations or
definitions to namespace <tt>std2</tt> or to a namespace within namespace
<tt>iso</tt> unless otherwise specified.
</li>
<li>
[<i>Note:</i> The namespace <tt>std2</tt> is reserved for use by future
revisions of this standard. <i>- end note</i>]
</li>
</ol>
</blockquote>

<p>
Insert the following rationale into the compatibility Annex C:
</p>

<blockquote>

<h4>C.4.x Removed Deprecated Feature [diff.cpp14.library]</h4>
<p>17.6.4.2.3</p>
<p><b>Change:</b> New reserved namespace</p>
<p><b>Rationale:</b> Reserve namespace for a revised standard library.</p>
<p>
<b>Effect on original feature:</b> The global namespace <tt>iso</tt> is now
reserved for standardization. Valid C++ 2014 code that uses a top-level
namespace <tt>std2</tt> may be invalid in this International Standard.
</p>
</blockquote>


<h2><a name="5.0">References</h2>
<ul>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2667">N2667</a> Reserved Namespace for POSIX, Benjamin Kosnik, Nick Stoughton</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4532">N4532</a> Proposed wording for default comparisons, Jens Maurer</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4553">N4553</a> Working Draft for Concepts TS</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4560">N4560</a> Working Draft for Ranges TS</li>
  <li><a href="https://isocpp.org/files/papers/p0143r0.pdf">P0143R0</a> Wording for Modules, Gabriel Dos Reis</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3421">N3421</a>Making Operator Functors greater&lt;&gt;, Stephan T. Lavavej</li>
  <li><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3451">N3451</a> async and ~future, Herb Sutter</li>
</ul>


</body>
</html>
