<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head>
    <title>'constexpr' feature macro concerns</title>
    <meta content="http://schemas.microsoft.com/intellisense/ie5" name="vs_targetSchema">
    <meta http-equiv="Content-Language" content="en-us">
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

    <style type="text/css">
        .addition { color: green; }
        .right { float:right }
        .changed-deleted { background-color: #CFF0FC ; text-decoration: line-through; display: none; }
        .addition.changed-deleted { color: green; background-color: #CFF0FC ; text-decoration: line-through; text-decoration: black double line-through; display: none; }
        .changed-added { background-color: #CFF0FC ;}
        .notes { background-color: gold ;}
        pre { line-height: 1.2; font-size: 10pt; margin-top: 25px; }
        .desc { margin-left: 35px; margin-top: 10px; padding:0; white-space: normal; font-family:monospace }
        body {max-width: 1024px; margin-left: 25px;}
        .lmargin50{margin-left: 50px;}
        .width_third{width: 33%;}
        .cppkeyword { color: blue; }
        .asmcostly { color: red; }
        .cppcomment { color: green; }
        .cppcomment > .cppkeyword{ color: green; }
        .cpptext { color: #2E8B57; }
        .cppaddition { background-color: #CFC; }
        .cppdeletion {  text-decoration: line-through; background-color: #FCC; }
        .stdquote { background-color: #ECECEC; font-family: Consolas,monospace; }
    </style>
    </head>
    <body bgcolor="#ffffff">
    <address>Document number: P1424R0</address>
    <address>Project: Programming Language C++</address>
    <address>Audience: SG10, Library Working group</address>
    <address>&nbsp;</address>
    <address>Antony Polukhin &lt;<a href="mailto:antoshkka@gmail.com">antoshkka@gmail.com</a>&gt;, &lt;<a href="mailto:antoshkka@yandex-team.ru">antoshkka@yandex-team.ru</a>&gt;</address>
    <address>&nbsp;</address>
    <address>Date: 2018-12-26</address>
    <h1>'constexpr' feature macro concerns</h1>

<!--div class="changed-added">
<p align="right">“...take no action on CWG #6 issue until an interested party<br> produces a paper with analysis and a proposal.”</p>
<p align="right"><i>― CWG #6</i></p>
</div>
    <p class='changed-added'>Significant changes since <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0889r0.html">P0889R0</a> are marked with blue.<p>
    <p><input type="checkbox" id="show_deletions" onchange="show_hide_deleted()"> Show deleted lines from P0889R0.</p-->

    <h2>I. Quick Introduction</h2>
    <p>In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1032r1.html">P1032R1 "Misc constexpr bits"</a> a feature testing macro <code>__cpp_lib_constexpr_misc</code> was proposed.</p>
    <p>That's not the best name for the macro. The name is not very informative. <code>__cpp_lib_constexpr_misc</code> also does not suite the needs of future constexprifications.</p>

    <p>This paper discuss different approaches for constexpr feature testing macro.</p>

    <h2>II. Approaches</h2>
    <h4>A. Single constexpr feature testing macro</h4>
    <p>Make a <code>__cpp_lib_constexpr</code> macro and increment its version on each new constexpr addition to the library.</p>
    <p>Pros:</p>
    <ul>
        <li>Simple to use and to remember</li>
    </ul>
    <p>Cons:</p>
    <ul>
        <li>Not vendor friendly - if there's a constexpr addition <i>A</i> followed by a constexpr addition <i>B</i> and <i>A</i> is hard to implement, then the vendor can not say that <i>B</i> is supported, even if it is implemented</li>
    </ul>


    <h4>B. Fuse constexpr feature testing into the feature testing macro of a component</h4>
    <p>Update the value of feature testing macro of a particular component. For example, update <code>_­_­cpp_­lib_­string_­view</code> with value <code>201811L</code> because <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1032r1.html">P1032R1 "Misc constexpr bits"</a> touched the <code>string_view</code>.</p>
    <p>Pros:</p>
    <ul>
        <li>Better granularity, more vendor friendly</li>
        <li>Simple to find</li>
    </ul>
    <p>Cons:</p>
    <ul>
        <li>Not many Standard library classes have their own feture testing macro. So with this approach each constexpr addition adds a bunch of feature testing macro to the [support.limits.general].</li>
    </ul>

    <h4>C. Have a feature testing macro per paper/proposal</h4>
    <p>This approach was taken by the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1032r1.html">P1032R1</a> with its <code>__cpp_lib_constexpr_misc</code> macro.</p>
    <p>Pros:</p>
    <ul>
        <li>Simple to detect that the particular paper is implemented by vendor</li>
    </ul>
    <p>Cons:</p>
    <ul>
        <li>Not vendor friendly - paper could be very big and the implementor may wish to implement part of it right now, leaving the remaining parts for the next release.</li>
    </ul>

<h2>III. Conclusions</h2>
  <p>Each approach has its own advantages and disadvantages. I'd like recommend the following generic approach:</p>
  <ul>
      <li>Each new constexpr paper should have either a new feature testing macro or should update the existing one.</li>
      <li>Introduce a <code>__cpp_lib_constexpr</code> macro and increase it on each LWG constexpr paper adoption.</li>
      <li>Listen to the Standard Library developers and users. Add feature testing macro on their request.</li>
  </ul>


    <script type="text/javascript">
    /*
        function colorize_texts(texts) {
        for (var i = 0; i < texts.length; ++i) {
            var text = texts[i].innerHTML;
            text = text.replace(/namespace|sizeof|long|enum|void|constexpr|extern|noexcept|bool|template|class |struct|auto|const|typename|explicit|public|private|operator|#include|inline| char|typedef|static_assert|int|return|union|static_cast|static/g,"<span class='cppkeyword'>$&<\/span>");
            text = text.replace(/\/\/[\s\S]+?\n/g,"<span class='cppcomment'>$&<\/span>");
            //text = text.replace(/\"[\s\S]+?\"/g,"<span class='cpptext'>$&<\/span>");
            texts[i].innerHTML = text;
        }
        }

        colorize_texts(document.getElementsByTagName("pre"));
        colorize_texts(document.getElementsByTagName("code"));



        function colorize_asm(texts) {
        for (var i = 0; i < texts.length; ++i) {
            var text = texts[i].innerHTML;
            text = text.replace(/operator new|std::__throw_length_error|std::__throw_logic_error|lock|operator delete|div/g,"<span class='asmcostly'>$&<\/span>");
            text = text.replace(/jmp|ja|je|mov[a-z]* |call|lea|cmp|rep|push|sub|add|ret|xor|pop|test|jne|js/g,"<span class='cppkeyword'>$&<\/span>");
            text = text.replace(/\/\/[\s\S]+?\n/g,"<span class='cppcomment'>$&<\/span>");
            //text = text.replace(/\"[\s\S]+?\"/g,"<span class='cpptext'>$&<\/span>");
            texts[i].innerHTML = text;
        }
        }

        colorize_asm(document.getElementsByTagName("td"));

        function show_hide_deleted() {
        var to_change = document.getElementsByClassName('changed-deleted');
        for (var i = 0; i < to_change.length; ++i) {
            to_change[i].style.display = (document.getElementById("show_deletions").checked ? 'block' : 'none');
        }
        }
        show_hide_deleted()
        */
    </script>
</body></html>

