<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.3.10: http://docutils.sourceforge.net/" />
<title>Please reconsider noexcept</title>
<meta name="author" content="Thorsten Ottosen" />
<meta name="date" content="2010-11-23" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:Date: $Date: 2005-09-25 17:49:54 +0200 (Sun, 25 Sep 2005) $
:Revision: $Revision: 3901 $
:Copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.

See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
customize this style sheet.
*/

/* "! important" is used here to override other ``margin-top`` and
   ``margin-bottom`` styles that are later in the stylesheet or 
   more specific.  See http://www.w3.org/TR/CSS1#the-cascade */
.first {
  margin-top: 0 ! important }

.last, .with-subtitle {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dl.docutils dd {
  margin-bottom: 0.5em }

/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
  font-weight: bold }
*/

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

/* Uncomment (and remove this text!) to get reduced vertical space in
   compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
  margin-bottom: 0.5em }

div.compound .compound-last, div.compound .compound-middle {
  margin-top: 0.5em }
*/

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  clear: both;
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
  margin-top: 0.4em }

h1.title {
  text-align: center }

h2.subtitle {
  text-align: center }

hr.docutils {
  width: 75% }

img.align-left {
  clear: left }

img.align-right {
  clear: right }

img.borderless {
  border: 0 }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee }

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

span.section-subtitle {
  /* font-size relative to parent (h1..h6 element) */
  font-size: 80% }

table.citation {
  border-left: solid thin gray }

table.docinfo {
  margin: 2em 4em }

table.docutils {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.footnote {
  border-left: solid thin black }

table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

table.docutils th.field-name, table.docinfo th.docinfo-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap ;
  padding-left: 0 }

h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
  font-size: 100% }

tt.docutils {
  background-color: #eeeeee }

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="please-reconsider-noexcept">
<h1 class="title">Please reconsider <tt class="docutils literal"><span class="pre">noexcept</span></tt></h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr><th class="docinfo-name">Author:</th>
<td>Thorsten Ottosen</td></tr>
<tr><th class="docinfo-name">Contact:</th>
<td><a class="first last reference" href="mailto:nesotto&#64;cs.aau.dk">nesotto&#64;cs.aau.dk</a></td></tr>
<tr class="field"><th class="docinfo-name">Organizations:</th><td class="field-body">The Machine Intelligence Group, Department of Computer Science, Aalborg University, Denmark</td>
</tr>
<tr><th class="docinfo-name">Date:</th>
<td>2010-11-23</td></tr>
<tr class="field"><th class="docinfo-name">Number:</th><td class="field-body">N3227=10-0217</td>
</tr>
<tr class="field"><th class="docinfo-name">Working Group:</th><td class="field-body">Evolution/Core</td>
</tr>
</tbody>
</table>
<div class="abstract topic">
<p class="topic-title first">Abstract</p>
<p>With the adoption of <a class="reference" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html">n3050</a> we have a new keyword <tt class="docutils literal"><span class="pre">noexcept</span></tt>
which allows the programmer to tell the compiler (and users) that a function
throws no exceptions. This has several good consequence, in particular 
(a) that interfaces are more self-documenting, and (b) that the compiler
can optimize code better. However, since the compiler is not allowed to
deduce if a function is <tt class="docutils literal"><span class="pre">noexcept</span></tt>, the new feature 
places a considerable
syntactical and maintenance burden on the programmer, so much in fact, 
that it seriously compromises a major design goal of C++0x: simplicity.
We therefore urge the committee to reconsider a 
compiler deduced <tt class="docutils literal"><span class="pre">noexcept</span></tt> for functions which the definition
is either immediate or has been previously seen.</p>
</div>
<!-- ######################### -->
<!-- # Roles -->
<!-- ######################### -->
<div class="contents topic">
<p class="topic-title first"><a id="table-of-contents" name="table-of-contents">Table of Contents</a></p>
<ul class="simple">
<li><a class="reference" href="#introduction" id="id1" name="id1">Introduction</a></li>
<li><a class="reference" href="#motivation" id="id2" name="id2">Motivation</a><ul>
<li><a class="reference" href="#example-1" id="id3" name="id3">Example 1</a></li>
<li><a class="reference" href="#example-2" id="id4" name="id4">Example 2</a></li>
<li><a class="reference" href="#example-3" id="id5" name="id5">Example 3</a></li>
<li><a class="reference" href="#example-4" id="id6" name="id6">Example 4</a></li>
</ul>
</li>
<li><a class="reference" href="#what-can-we-do-instead" id="id7" name="id7">What can we do instead?</a><ul>
<li><a class="reference" href="#objection-1-deducing-noexcept-is-undecidable" id="id8" name="id8">Objection 1: deducing <tt class="docutils literal"><span class="pre">noexcept</span></tt> is undecidable</a></li>
<li><a class="reference" href="#counter-argument-1-do-not-require-the-compiler-to-do-flow-analysis" id="id9" name="id9">Counter argument 1: do not require the compiler to do flow-analysis</a></li>
<li><a class="reference" href="#objection-2-no-flow-analysis-implies-compilation-inconsistencies" id="id10" name="id10">Objection 2: no flow-analysis implies compilation inconsistencies</a></li>
<li><a class="reference" href="#counter-argument-2-is-this-a-major-problem" id="id11" name="id11">Counter argument 2: is this a major problem?</a></li>
<li><a class="reference" href="#objection-3-no-flow-analysis-implies-runtime-inconsistencies" id="id12" name="id12">Objection 3: no flow-analysis implies runtime inconsistencies</a></li>
<li><a class="reference" href="#counter-argument-3-again-the-same-program-stays-portable" id="id13" name="id13">Counter argument 3: again, the same program stays portable</a></li>
<li><a class="reference" href="#objection-4-if-you-add-a-printf-some-levels-down-your-call-chain-to-debug-a-problem-that-might-switch-an-upper-level-algorithm-to-a-completely-different-code-base" id="id14" name="id14">Objection 4:  if you add a &quot;printf&quot; some levels down your call chain (to debug a problem), that might switch an upper-level algorithm to a completely different code base</a></li>
<li><a class="reference" href="#counter-argument-4-this-cascading-of-changes-can-already-happen" id="id15" name="id15">Counter argument 4: This cascading of changes can already happen.</a></li>
</ul>
</li>
<li><a class="reference" href="#summary" id="id16" name="id16">Summary</a></li>
<li><a class="reference" href="#acknowledgements" id="id17" name="id17">Acknowledgements</a></li>
</ul>
</div>
<!-- section-numbering: -->
<div class="section">
<h1><a class="toc-backref" href="#id1" id="introduction" name="introduction">Introduction</a></h1>
<p>We provide this paper as a point of reference. A preliminary paper lead to
lengthy discussions during the Batavia meeting. Therefore the paper
is also somewhat outdated as it does not include the discussion of the
Batavia meeting.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id2" id="motivation" name="motivation">Motivation</a></h1>
<p>To get all the performance benefits of a library
(which exploits the <tt class="docutils literal"><span class="pre">noexcept</span></tt> annotation with traits), e.g. the standard
library, the programmer has to sprinkle <tt class="docutils literal"><span class="pre">noexcept</span></tt> all over his code.
Below we give four simple examples where the use of <tt class="docutils literal"><span class="pre">noexcept</span></tt>
should (in an ideal world) not be needed.</p>
<div class="section">
<h2><a class="toc-backref" href="#id3" id="example-1" name="example-1">Example 1</a></h2>
<pre class="literal-block">
class Foo
{
   int i;
public:
   Foo() : i(0) {}
   Foo( const Foo&amp; r ) : i(r.i) {}
};
</pre>
<p>Why can't the compiler tell if these constructors
are <tt class="docutils literal"><span class="pre">noexcept</span></tt>?</p>
<p>Theres also a strange difference compared to defaulted constructors, i.e.,
these two constructors are indeed deduced as <tt class="docutils literal"><span class="pre">noexcept</span></tt>:</p>
<pre class="literal-block">
class Foo
{
   int i;
public:
   Foo() = default;
   Foo( const Foo&amp; r ) = default;
};
</pre>
<!-- If a novice forgets -->
<!-- to put ``noexcept`` on the declaration, is it OK that his code -->
<!-- is not  -->
</div>
<div class="section">
<h2><a class="toc-backref" href="#id4" id="example-2" name="example-2">Example 2</a></h2>
<pre class="literal-block">
template&lt; class T &gt;
struct numeric_limits
{
    static constexpr T max();
    ...
};    
</pre>
<p>What extra value do we get by making a <tt class="docutils literal"><span class="pre">constexpr</span></tt> function
<tt class="docutils literal"><span class="pre">noexcept</span></tt>? It is true
that one can construct <tt class="docutils literal"><span class="pre">constexpr</span></tt> 
functions that contain throw-statements, but the examples are 
somewhat contrived and can hardly be seen as normal.
For most programmers the above interface would be cluttered
with largely <cite>irrelevant</cite> information if we added <tt class="docutils literal"><span class="pre">noexcept</span></tt> to the 
declaration.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id5" id="example-3" name="example-3">Example 3</a></h2>
<p>Imagine a simple forwarding function. It might now
look like this:</p>
<pre class="literal-block">
template&lt; class T &gt;
auto forward_with_side_effect( T&amp; t ) noexcept( noexcept(bar(t)) &amp;&amp; noexcept(foo(t)) ) -&gt; decltype(foo(t))
{ 
    bar(t);
    return foo(t);
}
</pre>
<p>Do we really want to write and read code like this? It seems like a lot of 
key-strokes end up being devoted to something <cite>that is not of primary concern</cite>
to the programmer.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id6" id="example-4" name="example-4">Example 4</a></h2>
<p>When we start to consider templates, the syntactical and maintenance
burden becomes unlike anything C++ has ever seen before. The reason
is the following: <strong>any operation depending on one or more template parameters
potentially leaks into the declaration of the function.</strong></p>
<p>Consider just something as simple as <tt class="docutils literal"><span class="pre">std::pair</span></tt>. <a class="reference" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3157.html">n3157</a> now describes
the declaration of <tt class="docutils literal"><span class="pre">std::pair</span></tt> as follows</p>
<pre class="literal-block">
template &lt;class T1, class T2&gt;
struct pair {
  typedef T1 first_type;
  typedef T2 second_type;

  T1 first;
  T2 second;
  constexpr pair() noexcept( is_nothrow_constructible&lt;T1&gt;::value &amp;&amp;
                             is_nothrow_constructible&lt;T2&gt;::value );
  pair(const pair&amp;) = default;
  pair(const T1&amp; x, const T2&amp; y) noexcept( is_nothrow_constructible&lt;T1, const T1&amp;&gt;::value &amp;&amp;
                                           is_nothrow_constructible&lt;T2, const T2&amp;&gt;::value );
  ...
  void swap(pair&amp; p) noexcept( noexcept(swap(first, p.first)) &amp;&amp;
                               noexcept(swap(second, p.second)));
};
</pre>
<p>If you think the above code is difficult to read, then imagine putting
<tt class="docutils literal"><span class="pre">noexcept</span></tt> on something like <tt class="docutils literal"><span class="pre">std::sort()</span></tt>.</p>
<p>It can hardly be argued that the above code is clear, concise or simple.
<cite>Also note the strange difference between a defaulted constructor and one
that is not</cite>.</p>
<p>The programmer ought to be able to write</p>
<pre class="literal-block">
template &lt;class T1, class T2&gt;
struct pair {
  typedef T1 first_type;
  typedef T2 second_type;

  T1 first;
  T2 second;
  constexpr pair();
  pair(const pair&amp;) = default;
  pair(const T1&amp; x, const T2&amp; y);
  ...
  void swap(pair&amp; p);
};
</pre>
<p>and get all the same benefits.</p>
</div>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id7" id="what-can-we-do-instead" name="what-can-we-do-instead">What can we do instead?</a></h1>
<p>The solution appears to be quite simple: <cite>require the compiler to deduce
the</cite> <tt class="docutils literal"><span class="pre">noexcept</span></tt> <cite>specification for functions without using flow-analysis.</cite></p>
<p>This has already been discussed in the CWG and rejected. But the CWG did
not explicitly consider the solution above, and so the discussion was based on
<cite>incomplete</cite> information.</p>
<p>Other objections
has been put forward, e.g. on the reflector. We shall review all of these
objection again to give EWG/CWG a better foundation for a new discussion.</p>
<div class="section">
<h2><a class="toc-backref" href="#id8" id="objection-1-deducing-noexcept-is-undecidable" name="objection-1-deducing-noexcept-is-undecidable">Objection 1: deducing <tt class="docutils literal docutils literal"><span class="pre">noexcept</span></tt> is undecidable</a></h2>
<p>Rice's theorem tells us that any non-trivial property is undecidable. 
Hence in general it will be impossible for a compiler to come 
to the right conclusion in all cases, even with whole program analysis.
In turn, this implies that code might change when recompiled on a different
compiler, which is highly undesirable.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id9" id="counter-argument-1-do-not-require-the-compiler-to-do-flow-analysis" name="counter-argument-1-do-not-require-the-compiler-to-do-flow-analysis">Counter argument 1: do not require the compiler to do flow-analysis</a></h2>
<p>Instead, the <tt class="docutils literal"><span class="pre">noexcept</span></tt> specification of an inline function is determined
by a simple recursive test that all statements are <tt class="docutils literal"><span class="pre">noexcept</span></tt>, stopping the
recursion at non-inline functions and built-in statements.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id10" id="objection-2-no-flow-analysis-implies-compilation-inconsistencies" name="objection-2-no-flow-analysis-implies-compilation-inconsistencies">Objection 2: no flow-analysis implies compilation inconsistencies</a></h2>
<p>There can be at least two consequences of &quot;no flow-analysis&quot;. The first
is static in nature, pertaining to compilation only.</p>
<p>Changing an inline function to be non-inline (or vice versa)
can mean a compiling program no longer compiles because
the compiler could deduce the inline version was <tt class="docutils literal"><span class="pre">noexcept</span></tt>, but
the non-inline version does not specify this information in its declaration.</p>
<p>Then imagine
a <tt class="docutils literal"><span class="pre">static_assert</span></tt> that uses <tt class="docutils literal"><span class="pre">noexcept</span></tt> somehow. The outcome
of the static assertion will then change when the function is changed
between inline and non-inline.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id11" id="counter-argument-2-is-this-a-major-problem" name="counter-argument-2-is-this-a-major-problem">Counter argument 2: is this a major problem?</a></h2>
<p>There is really no counter argument to this. It can happen. It will
happen. The question is if this is a major problem, or even, if this
is even significant compared to the list of problems the current proposal
has.</p>
<!-- We shall later try to summarize the pros and cons of the different
approaches. -->
<p><em>Remark 1:</em> From the CWG Santa Cruz wiki it appears that the CWG had the 
same discussion, but in the context that the compiler-deduced <tt class="docutils literal"><span class="pre">noexcept</span></tt>
required whole-program analysis. This could lead to inconsistencies across
compilers. <cite>This is no longer possible with the no-flow-analysis approach.</cite> 
<strong>The same program stays portable.</strong></p>
<p><em>Remark 2:</em> With the current approach client code can also be broken
if the <tt class="docutils literal"><span class="pre">noexcept</span></tt> keyword is added or removed to a declaration.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id12" id="objection-3-no-flow-analysis-implies-runtime-inconsistencies" name="objection-3-no-flow-analysis-implies-runtime-inconsistencies">Objection 3: no flow-analysis implies runtime inconsistencies</a></h2>
<p>Because the outcome of <tt class="docutils literal"><span class="pre">noexcept</span></tt> can change when changing an
inline function to non-inline (or vice versa), it means that
different code paths gets executed in user and client code. For example,
different template specializations could get instantiated, leading
to untested code being executed.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id13" id="counter-argument-3-again-the-same-program-stays-portable" name="counter-argument-3-again-the-same-program-stays-portable">Counter argument 3: again, the same program stays portable</a></h2>
<p>The CWG saw this as very problematic. However, their context
was again that the compiler-deduced <tt class="docutils literal"><span class="pre">noexcept</span></tt>
required whole-program analysis. <cite>With the no-flow-analysis approach
this is not possible anymore.</cite></p>
<p>Now, in the new context, we can still get a similar problem. But this
is really nothing new: there are many ways an existing program can change
behavior silently if we <cite>change</cite> the program. Of course, that does not mean 
that we should not consider any effect of this kind.</p>
<!-- However, client code can still -->
</div>
<div class="section">
<h2><a class="toc-backref" href="#id14" id="objection-4-if-you-add-a-printf-some-levels-down-your-call-chain-to-debug-a-problem-that-might-switch-an-upper-level-algorithm-to-a-completely-different-code-base" name="objection-4-if-you-add-a-printf-some-levels-down-your-call-chain-to-debug-a-problem-that-might-switch-an-upper-level-algorithm-to-a-completely-different-code-base">Objection 4:  if you add a &quot;printf&quot; some levels down your call chain (to debug a problem), that might switch an upper-level algorithm to a completely different code base</a></h2>
<p>The headline says it all. If we allow the compiler to deduce <tt class="docutils literal"><span class="pre">noexcept</span></tt>
the code that changes might be non-local. This change occurs if and only
if</p>
<ol class="loweralpha simple">
<li>at least one of the statements being added can throw</li>
<li>all the other (old) statements in the changed function are deduced to be <tt class="docutils literal"><span class="pre">noexcept</span></tt></li>
<li>all outer (if any) functions in the <tt class="docutils literal"><span class="pre">noexcept</span></tt> expression
in the upper-level algorithm are deduced to be <tt class="docutils literal"><span class="pre">noexcept</span></tt>.</li>
</ol>
<p>Of course, it might happen. And it might happen that it changes code in many
unforseen places.</p>
</div>
<div class="section">
<h2><a class="toc-backref" href="#id15" id="counter-argument-4-this-cascading-of-changes-can-already-happen" name="counter-argument-4-this-cascading-of-changes-can-already-happen">Counter argument 4: This cascading of changes can already happen.</a></h2>
<p>Of course, deducing <tt class="docutils literal"><span class="pre">noexcept</span></tt> adds one more way this can happen,
but it is actually something already possible with the current
C++0x draft, albeit in a slightly different manner.</p>
<p>Think of all the new compiler deduced type-traits. Then
imagine we have a class so</p>
<pre class="literal-block">
class Foo
{ ... };
</pre>
<p>To begin with <tt class="docutils literal"><span class="pre">std::has_nothrow_copy_constructor&lt;Foo&gt;::value</span></tt>
is <tt class="docutils literal"><span class="pre">false</span></tt>. Then the author of <tt class="docutils literal"><span class="pre">Foo</span></tt> changes something, and
suddenly  <tt class="docutils literal"><span class="pre">std::has_nothrow_copy_constructor&lt;Foo&gt;::value</span></tt> is
<tt class="docutils literal"><span class="pre">true</span></tt>. This implies all kinds of non-local changes can happen
to clients of <tt class="docutils literal"><span class="pre">Foo</span></tt>:</p>
<pre class="literal-block">
class Bar
{ 
    Foo foo; 
};

class FooBar
{
    Bar bar;
};
</pre>
<p><tt class="docutils literal"><span class="pre">std::has_nothrow_copy_constructor&lt;FooBar&gt;::value</span></tt> might now also
become <tt class="docutils literal"><span class="pre">true</span></tt>. <cite>So a cascade of non-local changes is possible with
very small changes to a piece of code</cite>. In a wide range of ways, e.g.
changing <tt class="docutils literal"><span class="pre">noexcept</span></tt> specifications or making classes trivially
copyable.</p>
<!-- We can also consider how the programmer might guard against such
things happening:

.. parsed-literal::

    void foo()
    {
        ACME_DEBUG_STATEMENT( printf(...) );
    }
    
with the macros sourrounding the code with a ``try-catch(...)`` block. -->
<!-- Objection 5: Can't a deduced ``noexcept`` break callers that are not inlined?
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- Objection 6: we can't have noexcept(foo()) return different values at different points in the source code (or in different translations units)
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Objection 7: but doesn't an explicit ``noexcept`` enhance documentation?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -->
<!-- ==========================================
Further problems with the current proposal
========================================== -->
<!-- Extra problem 1: unintended calls to std::terminate() in costumer code
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

- dll updates
- 

Extra problem 2: 
++++++++++++++++ -->
</div>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id16" id="summary" name="summary">Summary</a></h1>
<p>We may summarize the problems
with the current <tt class="docutils literal"><span class="pre">noexcept</span></tt> approach as follows:</p>
<ul class="simple">
<li>users will be annoyed that the compiler cannot deduce
obvious cases, e.g. inline constructors/destructors.</li>
<li>simple interfaces are cluttered with non-essential information, e.g.
<tt class="docutils literal"><span class="pre">constexpr</span></tt> functions</li>
<li>almost every statement in function templates leak into the <tt class="docutils literal"><span class="pre">noexcept</span></tt>
declaration</li>
<li>a user-maintained
<tt class="docutils literal"><span class="pre">noexcept</span></tt> increases the likelihood that the specification is
not correct. In turn, this implies (a) an increased chance that client
code terminates unexpectedly, or (b) that optimization opportunities
are lost. (Note that providing correct warnings is also undecidable.)</li>
<li>client code can still change 
(fail to compile, different runtime behavior) if <tt class="docutils literal"><span class="pre">noexcept</span></tt> is
added or removed from a library.</li>
</ul>
<p>The only benefit compared to the no-flow-analysis approach we can think
of is that there is one less way to change client code, 
but as noted above, this requires <cite>changing</cite> the program. Also note
that there is ample opportunity for changing client code in this way
in C++0x; for example, <cite>just about any of the new compiler-supported
traits has this property</cite>.</p>
<p>In light of the above discussion we kindly urge the CWG/EWG to
reconsider the <tt class="docutils literal"><span class="pre">noexcept</span></tt> specification for functions with an immedate
definition or where the definition has been previously seen.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id17" id="acknowledgements" name="acknowledgements">Acknowledgements</a></h1>
<p>I was prompted to write the above discussion based on a CWG reflector
thread started by 
José Daniel García Sánchez. Bjarne Stroustrup, Jason Marrill,
Dave Abrahams, David Vandevoorde, Thomas Plum, Ville Voutilainen,
Martin Sebor, Christopher Jefferson, Gabriel Dos Reis, Jens Maurer,
Alberto Ganesh Barbati, Daniel Krügler, Herb Sutter, Matt Austern and
John Spicer were all deeply involved in the following
discussions of the noexcept feature.</p>
<!-- ====================== ====================== ====================== -->
<!-- Feature  Current ``noexcept``   deduced ``noexcept`` -->
</div>
</div>
</body>
</html>
