<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2013: Do library implementers have the freedom to add constexpr?</title>
<meta property="og:title" content="Issue 2013: Do library implementers have the freedom to add constexpr?">
<meta property="og:description" content="C++ library issue. Status: C++14">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2013.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++14">C++14</a> status.</em></p>
<h3 id="2013"><a href="lwg-defects.html#2013">2013</a>. Do library implementers have the freedom to add <code>constexpr</code>?</h3>
<p><b>Section:</b> 16.4.6.7 <a href="https://wg21.link/constexpr.functions">[constexpr.functions]</a> <b>Status:</b> <a href="lwg-active.html#C++14">C++14</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2010-11-12 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#constexpr.functions">issues</a> in [constexpr.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++14">C++14</a> status.</p>
<p><b>Discussion:</b></p>
<p>Suppose that a particular function is not tagged as constexpr in the standard,
but that, in some particular implementation, it is possible to write it within
the constexpr constraints. If an implementer tags such a function as constexpr,
is that a violation of the standard or is it a conforming extension?</p>

<p>There are two questions to consider. First, is this allowed under the
as-if rule? Second, if it does not fall under as-if, is there
(and should there be) any special license granted to implementers
to do this anyway, sort of the way we allow elision of copy constructors
even though it is detectable by users?</p>

<p>I believe that this does not fall under "as-if", so implementers
probably don't have that freedom today. I suggest changing the WP
to grant it. Even if we decide otherwise, however, I suggest that
we make it explicit.</p>

<p><i>[
2011 Bloomington
]</i></p>


<p>
General surprise this was not already in 'Ready' status, and so moved.
</p>

<p><i>[
2012 Kona
]</i></p>


<p>
Some concern expressed when presented to full committee for the vote to WP status
that this issue had been resolved without sufficient thought of the consequences
for diverging library implementations, as users may use SFINAE to observe
different behavior from otherwise identical code.  Issue moved back to Review
status, and will be discussed again in Portland with a larger group.

Note for Portland: John Spicer has agreed to represent Core's concerns during
any such discussion within LWG.
</p>

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


<p>
Straw poll: LWG strongly favoured to remove from implementations the freedom to add <code>constexpr</code>.
</p>
<p>
Matt provides new wording.
</p>

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


<p>
Move to Immediate after reviewing Matt's new wording, apply the new wording to the Working Paper.
</p>



<p id="res-2013"><b>Proposed resolution:</b></p>
<p><i>In 16.4.6.7 <a href="https://wg21.link/constexpr.functions">[constexpr.functions]</a>, change paragraph 1 to:</i></p>

<blockquote><p>
<ins>This standard explicitly requires that certain standard library functions
are <code>constexpr</code> [dcl.constexpr]. 
An implementation shall not declare any standard library function signature as <code>constexpr</code> 
except for those where it is explicitly required.</ins>
Within any header that provides any non-defining declarations of <code>constexpr</code>
functions or constructors an implementation shall provide corresponding definitions. 
</p></blockquote>






</body>
</html>
