Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r60456 - sandbox/committee/exceptions
From: dgregor_at_[hidden]
Date: 2010-03-10 22:48:49

Next message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60457 - sandbox/committee/exceptions"
Previous message: joel_at_[hidden]: "[Boost-commit] svn:boost r60455 - trunk/libs/spirit/example/scheme"

Author: dgregor
Date: 2010-03-10 22:48:49 EST (Wed, 10 Mar 2010)
New Revision: 60456
URL: http://svn.boost.org/trac/boost/changeset/60456

Log:
Introduce the notion of "compatible" exception-specifications for
redeclarations, and make this definition loose enough to permit
evolution from dynamic exception specifications to noexcept.

Text files modified:
   sandbox/committee/exceptions/d3051.html | 122 +++++++++++++++++++++++++++++++--------
   sandbox/committee/exceptions/deprecating-exception-specs.rst | 111 ++++++++++++++++++++++++++++++------
   2 files changed, 188 insertions(+), 45 deletions(-)

Modified: sandbox/committee/exceptions/d3051.html
==============================================================================
--- sandbox/committee/exceptions/d3051.html (original)
+++ sandbox/committee/exceptions/d3051.html 2010-03-10 22:48:49 EST (Wed, 10 Mar 2010)
@@ -332,10 +332,11 @@
index
<ul class="simple">
<li><a class="reference internal" href="#introduction" id="id4">Introduction</a></li>
-<li><a class="reference internal" href="#proposed-changes-to-standard-wording" id="id5">Proposed Changes to Standard Wording</a><ul>
-<li><a class="reference internal" href="#dynamic-storage-duration-basic-stc-dynamic" id="id6">3.7.4 Dynamic storage duration [basic.stc.dynamic]</a></li>
-<li><a class="reference internal" href="#exception-specifications-except-spec" id="id7">15.4 Exception specifications [except.spec]</a></li>
-<li><a class="reference internal" href="#d-5-dynamic-exception-specifications-depr-except-spec-dynamic" id="id8">D.5 Dynamic exception specifications [depr.except.spec.dynamic]</a></li>
+<li><a class="reference internal" href="#approach" id="id5">Approach</a></li>
+<li><a class="reference internal" href="#proposed-changes-to-standard-wording" id="id6">Proposed Changes to Standard Wording</a><ul>
+<li><a class="reference internal" href="#dynamic-storage-duration-basic-stc-dynamic" id="id7">3.7.4 Dynamic storage duration [basic.stc.dynamic]</a></li>
+<li><a class="reference internal" href="#exception-specifications-except-spec" id="id8">15.4 Exception specifications [except.spec]</a></li>
+<li><a class="reference internal" href="#d-5-dynamic-exception-specifications-depr-except-spec-dynamic" id="id9">D.5 Dynamic exception specifications [depr.except.spec.dynamic]</a></li>
</ul>
</li>
</ul>
@@ -382,12 +383,64 @@
"dynamic" exception specifications, i.e., those based on
<tt class="docutils literal">noexcept</tt>.
</div>
+<div class="section" id="approach">
+<h1><a class="toc-backref" href="#id5">Approach</a></h1>
+The general approach taken by this paper is to separate the wording
+required for dynamic exception specifications (those using <tt class="docutils literal">throw</tt>)
+into a new, deprecated section D.5, while maintaining the description
+of <tt class="docutils literal">noexception</tt> and the general behavior of exception
+specifications in 15.4. The intent of the revised 15.4 (and core
+language in general) is to minimize the number of dependencies on
+the deprecated section D.5, and to mark each of those with a
+cross-reference.
+To aid in the transition from dynamic exception specifications to
+<tt class="docutils literal">noexcept</tt>, the wording provides somewhat loose compatibility rules
+for redeclarations of functions that have exception
+specifications. Two rules stand out:
+<blockquote>
+1) All "non-throwing" forms of exception specifications
+(<tt class="docutils literal">throw()</tt>, <tt class="docutils literal">noexcept</tt>, <tt class="docutils literal">noexcept(true)</tt>) are considered
+compatible, but the exception specification on the definition is
+what affects code generation:
+<pre class="literal-block">
+// header ultramodern.h
+void f() noexcept;
+
+// source plodding.cpp
+#include "ultramodern.h"
+struct X { };
+void f() throw() { // okay, compatible with noexcept
+ throw X(); // calls std::unexpected()
+}
+</pre>
+2) noexcept(false) is considered compatible with <tt class="docutils literal">throw(</tt>
+type-id-list <tt class="docutils literal">)</tt>:
+<pre class="literal-block">
+// header ultramodern.h
+void g() noexcept(false);
+
+// source plodding.cpp
+#include "ultramodern.h"
+struct X { };
+void g() throw(X) { // okay, compatible with noexcept(false)
+ throw X(); // okay
+}
+</pre>
+</blockquote>
+These compatibility rules allow a gradual migration from dynamic
+exception specifications to <tt class="docutils literal">noexcept</tt>, since a declaration of a
+function can choose to use the new or old syntax independently in the
+declaration and in the definition. This is particularly important with
+the implicit declarations of <tt class="docutils literal">operator new</tt>, <tt class="docutils literal">operator new[]</tt>,
+<tt class="docutils literal">operator delete</tt>, and <tt class="docutils literal">operator delete[]</tt>, which this document
+changes to use <tt class="docutils literal">noexcept</tt>.
+</div>
<div class="section" id="proposed-changes-to-standard-wording">
-<h1><a class="toc-backref" href="#id5">Proposed Changes to Standard Wording</a></h1>
+<h1><a class="toc-backref" href="#id6">Proposed Changes to Standard Wording</a></h1>
The wording in this paper is based on the current working paper
(N3035) as amended by N3050.
<div class="section" id="dynamic-storage-duration-basic-stc-dynamic">
-<h2><a class="toc-backref" href="#id6">3.7.4 Dynamic storage duration [basic.stc.dynamic]</a></h2>
+<h2><a class="toc-backref" href="#id7">3.7.4 Dynamic storage duration [basic.stc.dynamic]</a></h2>
Modify paragraph 2 as follows:
<blockquote>
2 The library provides default definitions for the global allocation
@@ -399,8 +452,8 @@
deallocation functions (18.6) are implicitly declared in global
scope in each translation unit of a program.
<pre class="literal-block">
-void* operator new(std::size_t) throw(std::bad_alloc);
-void* operator new[](std::size_t) throw(std::bad_alloc);
+void* operator new(std::size_t) throw(std::bad_alloc) noexcept(false);
+void* operator new[](std::size_t) throw(std::bad_alloc) noexcept(false);
void operator delete(void*) throw() noexcept;
void operator delete[](void*) throw() noexcept;
</pre>
@@ -420,11 +473,13 @@
</blockquote>
</div>
<div class="section" id="exception-specifications-except-spec">
-<h2><a class="toc-backref" href="#id7">15.4 Exception specifications [except.spec]</a></h2>
+<h2><a class="toc-backref" href="#id8">15.4 Exception specifications [except.spec]</a></h2>
Modify the paragraphs in this section as follows. Note that every
paragraph in this section is accounted for (even those that have not
changed), to ease review. Editorial notes are [Yellow] and will
-describe, e.g., when specific paragraphs have been moved.
+describe, e.g., when specific paragraphs have been moved. The
+paragraphs are numbered as in the working paper, but are ordered as
+they should appear after the following edits are applied.
<blockquote>
1 A function declaration lists exceptions that its function might
directly or indirectly throw by using an exception-specification
@@ -473,21 +528,6 @@
exception-specification shall not denote a pointer or reference to an
incomplete type, other than void*, const void*, volatile void*, or
const volatile void*.
-3 If any declaration of a function has an exception-specification,
-all declarations, including the definition and an explicit
-specialization, of that function shall have an
-exception-specification with the same set of type-id s.
-[FIXME: Note about what it means to have the same set of type-ids?]
-If any declaration of a pointer to function, reference to function, or
-pointer to member function has an exception-specification, all
-occurrences of that declaration shall have an
-exception-specification with the same set of type-id s. In an
-explicit instantiation an exception-specification may be specified,
-but is not required. If an exception-specification is specified in
-an explicit instantiation directive, it shall have the same set of
-type-id s as other declarations of that function. A diagnostic is
-required only if the sets of type-id s are different within a single
-translation unit.
4 [FIXME: Figure out what to do with p4!]
5 [FIXME: Figure out what to do with p5!]
6 [Moved to D.5p3] An
@@ -541,6 +581,36 @@
. A function with a
non-throwing exception-specification does not allow any
exceptions.
+[New paragraph] Two
+exception-specifications are compatible if:
+<blockquote>
+<ul class="simple">
+<li>both are non-throwing (regardless of their form), </li>
+<li>both have the form <code>noexcept(constant-expression)</code> and the constant-expressions are equivalent,</li>
+<li>one exception-specification is of the form <code>noexcept(false)</code> and the other is of the form <code>throw(type-id-list)</code> (D.5), or</li>
+<li>both are dynamic-exception-specifications (D.5) that have the same set of type-ids.</li>
+</ul>
+</blockquote>
+3 If any declaration of a function has an exception-specification,
+all declarations, including the definition and an explicit
+specialization, of that function shall have an compatible exception-specification
+with the same set of type-ids. If
+any declaration of a pointer to function, reference to function, or
+pointer to member function has an exception-specification, all
+occurrences of that declaration shall have an compatible exception-specification
+with the same set of type-ids. In an
+explicit instantiation an exception-specification may be
+specified, but is not required. If an exception-specification is
+specified in an explicit instantiation directive, it shall
+have the
+same set of type-ids asbe compatible
+to the exception-specifications of other declarations
+of that function.
+A diagnostic is required only if the sets of type-ids are
+differentexception-specifications
+are not compatible within a single translation unit.
12 An exception-specification is not considered part of a function's
type.
13 [FIXME: Figure out what to do with p13!]
@@ -550,7 +620,7 @@
</blockquote>
</div>
<div class="section" id="d-5-dynamic-exception-specifications-depr-except-spec-dynamic">
-<h2><a class="toc-backref" href="#id8">D.5 Dynamic exception specifications [depr.except.spec.dynamic]</a></h2>
+<h2><a class="toc-backref" href="#id9">D.5 Dynamic exception specifications [depr.except.spec.dynamic]</a></h2>
Insert this new section. Green underlined text is used to
indicate new wording, while normal text is used whenever text was
moved from another section (15.4, 15.5).

Modified: sandbox/committee/exceptions/deprecating-exception-specs.rst
==============================================================================
--- sandbox/committee/exceptions/deprecating-exception-specs.rst (original)
+++ sandbox/committee/exceptions/deprecating-exception-specs.rst 2010-03-10 22:48:49 EST (Wed, 10 Mar 2010)
@@ -60,6 +60,64 @@
"dynamic" exception specifications, i.e., those based on
``noexcept``.

+Approach
+********
+
+The general approach taken by this paper is to separate the wording
+required for dynamic exception specifications (those using ``throw``)
+into a new, deprecated section D.5, while maintaining the description
+of ``noexception`` and the general behavior of exception
+specifications in 15.4. The intent of the revised 15.4 (and core
+language in general) is to minimize the number of dependencies on
+the deprecated section D.5, and to mark each of those with a
+cross-reference.
+
+To aid in the transition from dynamic exception specifications to
+``noexcept``, the wording provides somewhat loose compatibility rules
+for redeclarations of functions that have exception
+specifications. Two rules stand out:
+
+ 1) All "non-throwing" forms of exception specifications
+ (``throw()``, ``noexcept``, ``noexcept(true)``) are considered
+ compatible, but the exception specification on the definition is
+ what affects code generation:
+
+ .. parsed-literal::
+
+ // header ultramodern.h
+ void f() noexcept;
+
+ // source plodding.cpp
+ #include "ultramodern.h"
+ struct X { };
+ void f() throw() { // okay, compatible with noexcept
+ throw X(); // calls std::unexpected()
+ }
+
+
+ 2) noexcept(false) is considered compatible with ``throw(``
+ *type-id-list* ``)``:
+
+ .. parsed-literal::
+
+ // header ultramodern.h
+ void g() noexcept(false);
+
+ // source plodding.cpp
+ #include "ultramodern.h"
+ struct X { };
+ void g() throw(X) { // okay, compatible with noexcept(false)
+ throw X(); // okay
+ }
+
+These compatibility rules allow a gradual migration from dynamic
+exception specifications to ``noexcept``, since a declaration of a
+function can choose to use the new or old syntax independently in the
+declaration and in the definition. This is particularly important with
+the implicit declarations of ``operator new``, ``operator new[]``,
+``operator delete``, and ``operator delete[]``, which this document
+changes to use ``noexcept``.
+
Proposed Changes to Standard Wording
************************************

@@ -99,8 +157,8 @@

 .. parsed-literal::

- void* operator new(std::size_t) :del:`throw(std::bad_alloc)`;
- void* operator new[](std::size_t) :del:`throw(std::bad_alloc)`;
+ void* operator new(std::size_t) :del:`throw(std::bad_alloc)` :ins:`noexcept(false)`;
+ void* operator new[](std::size_t) :del:`throw(std::bad_alloc)` :ins:`noexcept(false)`;
 void operator delete(void*) :del:`throw()` :ins:`noexcept`;
 void operator delete[](void*) :del:`throw()` :ins:`noexcept`;

@@ -124,7 +182,9 @@
Modify the paragraphs in this section as follows. Note that every
paragraph in this section is accounted for (even those that have not
changed), to ease review. Editorial notes are :ed:`[Yellow]` and will
-describe, e.g., when specific paragraphs have been moved.
+describe, e.g., when specific paragraphs have been moved. The
+paragraphs are numbered as in the working paper, but are ordered as
+they should appear after the following edits are applied.

 1 A function declaration lists exceptions that its function might
 directly or indirectly throw by using an *exception-specification*
@@ -178,22 +238,6 @@
 incomplete type, other than void\*, const void\*, volatile void\*, or
 const volatile void\*.`

- 3 If any declaration of a function has an *exception-specification*,
- all declarations, including the definition and an explicit
- specialization, of that function shall have an
- *exception-specification* with the same set of *type-id* s.
- :ed:`[FIXME: Note about what it means to have the same set of type-ids?]`
- If any declaration of a pointer to function, reference to function, or
- pointer to member function has an *exception-specification*, all
- occurrences of that declaration shall have an
- *exception-specification* with the same set of *type-id* s. In an
- explicit instantiation an *exception-specification* may be specified,
- but is not required. If an *exception-specification* is specified in
- an explicit instantiation directive, it shall have the same set of
- *type-id* s as other declarations of that function. A diagnostic is
- required only if the sets of *type-id* s are different within a single
- translation unit.
-
 4 :ed:`[FIXME: Figure out what to do with p4!]`

 5 :ed:`[FIXME: Figure out what to do with p5!]`
@@ -257,6 +301,35 @@
 non-throwing *exception-specification* does not allow any
 exceptions.

+ :ed:`[New paragraph]` :raw-html:`Two
+ exception-specifications are compatible if:`
+
+ * :raw-html:`both are non-throwing (regardless of their form), `
+ * :raw-html:`both have the form <code>noexcept(constant-expression)</code> and the constant-expressions are equivalent,`
+ * :raw-html:`one exception-specification is of the form <code>noexcept(false)</code> and the other is of the form <code>throw(type-id-list)</code> (D.5), or`
+ * :raw-html:`both are dynamic-exception-specifications (D.5) that have the same set of type-ids.`
+
+ 3 If any declaration of a function has an *exception-specification*,
+ all declarations, including the definition and an explicit
+ specialization, of that function shall have an :raw-html:`compatible exception-specification
+ with the same set of type-ids.` If
+ any declaration of a pointer to function, reference to function, or
+ pointer to member function has an *exception-specification*, all
+ occurrences of that declaration shall have an :raw-html:`compatible exception-specification
+ with the same set of type-ids.` In an
+ explicit instantiation an *exception-specification* may be
+ specified, but is not required. If an *exception-specification* is
+ specified in an explicit instantiation directive, it shall
+ :raw-html:`have the
+ same set of type-ids asbe compatible
+ to the exception-specifications of` other declarations
+ of that function.
+ A diagnostic is required only if the :raw-html:`sets of type-ids are
+ differentexception-specifications
+ are not compatible` within a single translation unit.
+
 12 An *exception-specification* is not considered part of a function's
 type.

Next message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60457 - sandbox/committee/exceptions"
Previous message: joel_at_[hidden]: "[Boost-commit] svn:boost r60455 - trunk/libs/spirit/example/scheme"

Date view	Thread view	Subject view	Author view

Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk