<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2296: std::addressof should be constexpr</title>
<meta property="og:title" content="Issue 2296: std::addressof should be constexpr">
<meta property="og:description" content="C++ library issue. Status: C++17">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2296.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#C++17">C++17</a> status.</em></p>
<h3 id="2296"><a href="lwg-defects.html#2296">2296</a>. <code>std::addressof</code> should be <code>constexpr</code></h3>
<p><b>Section:</b> 20.2.11 <a href="https://wg21.link/specialized.addressof">[specialized.addressof]</a> <b>Status:</b> <a href="lwg-active.html#C++17">C++17</a>
 <b>Submitter:</b> Daryle Walker <b>Opened:</b> 2013-09-08 <b>Last modified:</b> 2017-07-30</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#specialized.addressof">issues</a> in [specialized.addressof].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++17">C++17</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I'm writing a function that needs to be <code>constexpr</code> and I wanted to take the address of its input. I was 
thinking of using <code>std::addressof</code> to be safe, but it isn't currently <code>constexpr</code>. A 
<a href="http://en.cppreference.com/w/cpp/memory/addressof">sample implementation</a> 
couldn't be <code>constexpr</code> under the C++11 rules, though.
<p/>
Daniel Kr&uuml;gler:
<p/>
Indeed the core language clarified by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1312">CWG 1312</a> 
and by <a href="www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1384">CWG 1384</a>, that such emulations of <code>std::addressof</code>
implementations are not valid in constant expressions, therefore it seems more like a defect than a feature request to ask for 
the guarantee that <code>std::addressof</code> is a <code>constexpr</code> function. It should be added that a similar requirement
already exists for <code>offsetof</code> indirectly via the C99 standard as of 7.17 p3:
</p>
<blockquote>
<p>
The macros are [&hellip;]
</p>
<blockquote><pre>
offsetof(type, member-designator)
</pre></blockquote>
<p>
which expands to an integer constant expression that has type <code>size_t</code> [&hellip;]
</p>
</blockquote>

<p>
combined with the noted property in C++11 that:
</p>

<blockquote><p>
"<code>offsetof</code> is required to work as specified even if unary <code>operator&amp;</code> 
is overloaded for any of the types involved"
</p></blockquote>

<p>
Therefore implementations should already be able without heroic efforts to realize this functionality by
some intrinsic. The wording needs at least to ensure that for any lvalue core constant expression <code><em>e</em></code>
the expression <code>std::addressof(<em>e</em>)</code> is a core constant expression.
</p>

<p><i>[2013-09 Chicago]</i></p>

<p>
</p>

<p><i>[2014-06-08, Daniel improves wording]</i></p>

<p>
It has been ensured that the wording is in sync with the recent working paper and the usage of "any" has been
improved to say "every" instead (the fix is similar to that applied by LWG <a href="lwg-defects.html#2150" title="Unclear specification of find_end (Status: C++14)">2150</a><sup><a href="https://cplusplus.github.io/LWG/issue2150" title="Latest snapshot">(i)</a></sup>).
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Change header <code>&lt;memory&gt;</code> synopsis, 20.2.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a> as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  <i>// 26.11 <a href="https://wg21.link/specialized.algorithms">[specialized.algorithms]</a>, specialized algorithms:</i>
  template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 20.2.11 <a href="https://wg21.link/specialized.addressof">[specialized.addressof]</a> as indicated:</p>

<blockquote><pre>
template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
</pre><blockquote>
<p>
-1- <i>Returns:</i> The actual address of the object or function referenced by <code>r</code>, even in the presence of an
overloaded <code>operator&amp;</code>.
<p/>
<ins>-?- <i>Remarks:</i> For every lvalue core constant expression <code><em>e</em></code> (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>), the expression 
<code>std::addressof(<em>e</em>)</code> is a core constant expression.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>
</blockquote>

<p><i>[2014-06-09, further improvements]</i></p>

<p>
A new wording form is now used similar to the approach used by LWG <a href="lwg-defects.html#2234" title="assert() should allow usage in constant expressions (Status: C++17)">2234</a><sup><a href="https://cplusplus.github.io/LWG/issue2234" title="Latest snapshot">(i)</a></sup>, which
is a stricter way to impose the necessary implementation requirements.
</p>

<p><i>[2015-05, Lenexa]</i></p>

<p>
 STL: the intent of this change is good; I think the wording is good<br/>
- I'm a bit worried about asking for a compiler hook<br/>
- if every implementer says: yes they can do it we should be good<br/>
EB: there is missing the word "a" before "subexpression" (in multiple places)<br/>
MC: the editor should do - we rely on our editors<br/>
MC: move to Review with a note stating that we wait for implementation experience first<br/>
- in favor: 13, opposed: 0, abstain: 2
HB: N4430 will bring something which is addressing this issue<br/>
MC: good we didn't go to ready then 
</p>


<p id="res-2296"><b>Proposed resolution:</b></p>
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Introduce the following new definition to the existing list in  [definitions]: [<i>Drafting note</i>:
If LWG <a href="lwg-defects.html#2234" title="assert() should allow usage in constant expressions (Status: C++17)">2234</a><sup><a href="https://cplusplus.github.io/LWG/issue2234" title="Latest snapshot">(i)</a></sup> is accepted before this issue, the accepted wording for the new definition should be used instead
&mdash; <i>end drafting note</i>]</p>

<blockquote>
<p>
<strong>constant subexpression</strong> [defns.const.subexpr]
<p/>
an expression whose evaluation as a subexpression of a <em>conditional-expression</em> <em>CE</em> (7.6.16 <a href="https://wg21.link/expr.cond">[expr.cond]</a>) 
would not prevent <em>CE</em> from being a core constant expression (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>).
</p>
</blockquote>
</li>

<li><p>Change header <code>&lt;memory&gt;</code> synopsis, 20.2.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a> as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  <i>// 26.11 <a href="https://wg21.link/specialized.algorithms">[specialized.algorithms]</a>, specialized algorithms:</i>
  template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
  [&hellip;]
}
</pre></blockquote>
</li>

<li><p>Change 20.2.11 <a href="https://wg21.link/specialized.addressof">[specialized.addressof]</a> as indicated:</p>

<blockquote><pre>
template &lt;class T&gt; <ins>constexpr</ins> T* addressof(T&amp; r) noexcept;
</pre><blockquote>
<p>
-1- <i>Returns:</i> The actual address of the object or function referenced by <code>r</code>, even in the presence of an
overloaded <code>operator&amp;</code>.
<p/>
<ins>-?- <i>Remarks:</i> An expression <code>std::addressof(<em>E</em>)</code> is a constant subexpression (3.15 <a href="https://wg21.link/defns.const.subexpr">[defns.const.subexpr]</a>), 
if <code><em>E</em></code> is an lvalue constant subexpression.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>






</body>
</html>
