<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 for 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">P0180R2</td>
</tr>
<tr>
  <td align="left">Date:</td>
  <td align="left">2016-06-23</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">Revision History</a></li>
  <ul>
  <li><a href="#0.0">Revision 0</a></li>
  <li><a href="#0.1">Revision 1</a></li>
  <li><a href="#0.2">Revision 2</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">Acknowledgements</a></li>
<li><a href="#6.0">References</a></li>
</ol>


<h2><a name="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>

<h3><a name="0.2">Revision 1</a></h3>
<p>
Revisions based on Jacksonville review...
</p>


<h3><a name="0.3">Revision 2</a></h3>
<p>
Adopt reserved namespace pattern chosen by LEWG in Oulu.
</p>

<p>
Refine the wording for reserved namespaces, and ensuring that only top-level
namespaces are reserved.
</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="3.4">Suggestions for a namespace</a></h3>
<p>
The library Evolution Working Group came up with two suggestions, that should
be pursued in parallel.  The first was that we should use a name that is not
otherwise available to the user, either by using characters that would not
otherwise be valid for an identifier (e.g., <tt>c++</tt>) or by recycling a
keyword (e.g., <tt>export</tt>).  This would require a complicit compiler,
and should be pursued with the Evolution Working Group.
</p>
<p>
The second option was to brainstorm as many reasonable (or unreasonable)
sounding names as we might consider, and then perform due diligence with
various code-searching tools between now and the next meeting, to see which
candidate names might still be reasonable to consider.
</p>
<p>
The shortlist on names supplied by brainstorming in LEWG was:
</p>
<ul>
  <li>cpp</li>
  <li>cxx</li>
  <li>lib</li>
  <li>std2</li>
  <li><ins>std\d* [regex]</ins></li>
  <li>stdex</li>
  <li>stdlib</li>
  <li>ste</li>
  <li>stx</li>
  <li>std.* [regex]</li>
  <li>wg21</li>
  <li>xtd</li>
</ul>


<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 Namespaces for future standardization [namespace.future]</h4>
<p>
<ol>
<li>
Top level namespaces with a name starting with <tt>std</tt> and followed
by a non-empty sequence of digits are reserved for future standardization.
The behavior of a C++ program is undefined if it adds declarations or
definitions to such a namespace.
</li>
<li>
[<i>Example:</i> The top level namespace <tt>std2</tt> is reserved for use by
future revisions of this standard. <i>- end example</i>]
</li>
</ol>
</blockquote>

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

<blockquote>

<h4>C.4.x Constraints on programs [diff.cpp14.cnostraints]</h4>
<p>17.6.4.2.3</p>
<p><b>Change:</b> New reserved namespaces</p>
<p><b>Rationale:</b> Reserve namespaces for future revisions of the standard
library that might otherwise be incompatible with existing programs.</p>
<p>
<b>Effect on original feature:</b> The global namespaces <tt>std</tt> followed
by an arbitrary sequence of digits is reserved for future standardization.
Valid C++ 2014 code that uses such a top-level namespace, e.g., <tt>std2</tt>,
may be invalid in this International Standard.
</p>
</blockquote>


<h2><a name="5.0">Acknowledgements</h2>
<p>
Thanks to Titus Winters for volunteering to help manage the code searches.
</p>

<h2><a name="6.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>
