Destructible no longer requires a sane address-of operator, per reque…

…st of the Committee, Kona 2016.

ext/constructible/constructible.md

@@ -154,30 +154,27 @@ In the "Proposed Resolution" that follows, there are editorial notes that highli
 > > <tt>&nbsp;&nbsp;&nbsp;&nbsp;<del>{ &amp;ct } -&gt; Same&lt;const T\*&gt;; // not required to be equality preserving</del></tt>
 > > <tt>&nbsp;&nbsp;&nbsp;&nbsp;<del>delete p;</del></tt>
 > > <tt>&nbsp;&nbsp;&nbsp;&nbsp;<del>delete[] p;</del></tt>
-> > <tt>&nbsp;&nbsp;<ins>return is_nothrow_destructible&lt;T&gt;::value &amp;&amp; // see below</ins></tt>
-> > <tt>&nbsp;&nbsp;&nbsp;&nbsp;<ins>requires(T&amp; t, const remove_reference_t&lt;T&gt;&amp; ct) {</ins></tt>
-> > <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<ins>{ &t } -&gt; Same&lt;remove_reference_t&lt;T&gt;\*&gt;&amp;&amp;; // not required to be equality preserving</ins></tt>
-> > <tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<ins>{ &ct } -&gt; Same&lt;const remove_reference_t&lt;T&gt;\*&gt;&amp;&amp;; // not required to be equality preserving</ins></tt>
-> > <tt>&nbsp;&nbsp;&nbsp;&nbsp;};</tt>
+> > <tt>&nbsp;&nbsp;<ins>return is_nothrow_destructible&lt;T&gt;::value; // see below</ins></tt>
+> > <tt>&nbsp;&nbsp;&nbsp;&nbsp;<del>};</del></tt>
 > > <tt>}</tt>
 >
-> 2 The expression requirement `&ct` does not require implicit expression variants.
+> &#8203;<del>2 The expression requirement `&ct` does not require implicit expression variants.</del>
 >
-> 3 Given a (possibly `const`) lvalue `t` of type <tt><ins>remove_reference_t&lt;</ins>T<ins>&gt;</ins></tt><del> and pointer `p` of type `T*`</del>,  `Destructible<T>()` is satisfied if and only if
+> &#8203;<del>3 Given a (possibly `const`) lvalue `t` of type <tt>T</tt> and pointer `p` of type `T*`,  `Destructible<T>()` is satisfied if and only if</del>
 >
 > > &#8203;<del>(3.1) -- After evaluating the expression `t.~T()`, `delete p`, or `delete[] p`, all resources owned by the denoted object(s) are reclaimed.</del>
 > >
-> > (3.<del>2</del><ins>1</ins>) -- `&t == addressof(t)`.
+> > &#8203;<del>(3.2) -- `&t == addressof(t)`.</del>
 > >
-> > (3.<del>3</del><ins>2</ins>) -- The expression `&t` is non-modifying.
+> > &#8203;<del>(3.3) -- The expression `&t` is non-modifying.</del>
 >
-> &#8203;<ins>4 There need not be any subsumption relationship between `Destructible<T>()` and `is_nothrow_destructible<T>::value`.
+> &#8203;<ins>2 There need not be any subsumption relationship between `Destructible<T>()` and `is_nothrow_destructible<T>::value`.
 
 <ednote>[_Editor's note:_ In the minutes of Ranges TS wording review at Kona on 2015-08-14, the following is recorded:</ednote>
 
 <blockquote><ednote>In 19.4.1 Alisdair asks whether reference types are Destructible. Eric pointed to <a href="https://github.com/ericniebler/stl2/issues/70">issue 70</a>, regarding reference types and array types. Alisdair concerned that Destructible sounds like something that goes out of scope, maybe this concept is really describing Deletable.</ednote></blockquote>
 
-<ednote>We took this as guidance to make `Destructible` behave more like the type traits with regard to "strange" types like references and arrays. We also dropped the requirement for dynamic [array] deallocation. We keep the requirement for a sane address-of operation since we recall previously receiving guidance from the committee to do so (although the notes don't seem to reflect this). We additionally require that destructors are marked `noexcept` since `noexcept` clauses throughout the standard and the Ranges TS tacitly assume it, and because sane implementations require it.]</ednote>
+<ednote>We took this as guidance to make `Destructible` behave more like the type traits with regard to "strange" types like references and arrays. We also dropped the requirement for dynamic [array] deallocation. Per discussion in Kona 2016, we drop the requirement for a sane address-of operation. We require that destructors are marked `noexcept` since `noexcept` clauses throughout the standard and the Ranges TS tacitly assume it, and because sane implementations require it.]</ednote>
 
 <ednote>[_Editor's note:_ Move subsection "Concept `Constructible`" ([concepts.lib.object.constructible]) to subsection "Core language concepts" ([concepts.lib.corelang]) after [concepts.lib.corelang.destructible], change its stable id to [concepts.lib.corelang.constructible] and edit it as follows:]</ednote>