<div dir="ltr"><div>Hi clang experts,</div><div><br></div><div>I submitted a constexpr-related paper to the C++ standards committee about</div><div>6 months ago.  To summarize the paper, I want to find a way to:</div><div>
<br></div><div> a. Allow constexpr code to have two implementations: one for constant</div><div>    evaluation, and one for runtime evaluation.</div><div><br></div><div> b. I also wish for a way for a programmer to insist that a particular</div>
<div>    constexpr function may only be used for constant evaluation.  If the</div><div>    constexpr function were to generate runtime code I want to be able</div><div>    to generate a compile- or link-time error.</div>
<div><br></div><div>The full version of the paper can be found here:</div><div><br></div><div><a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3583.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3583.pdf</a></div>
<div><br></div><div>Reception from the committee was somewhat chilly.  But they said that if I</div><div>were to pursue the project, I should try Approach C: a trait.</div><div><br></div><div>Richard Smith kindly offered some additional advice about such a trait.</div>
<div>Here's my interpretation of Richard's suggestion:</div><div><br></div><div> o Create a nullary trait named</div><div><br></div><div>      constexpr bool std::is_constant_evaluation().</div><div><br></div><div>
   It is not a template and it accepts no arguments.</div><div><br></div><div> o The return value of this trait depends on the context in which it</div><div>   is called.  If it is called in a situation that requires compile-time</div>
<div>   evaluation of a value, then it returns true.  One such situation </div><div>   occurs when a variable that is declared constexpr is evaluated.  Another</div><div>   such situation is when an Integer Constant Expression (ICE) is required.</div>
<div>   Yet another such situation is when a static_assert is evaluated.  There</div><div>   may be other similar situations as well.</div><div><br></div><div> o Under all other situations, the trait returns false.</div><div>
<br></div><div>Such a trait could be used with a conditional in a constexpr function to</div><div>select between a compile-time or a run-time implementation.</div><div> </div><div>I'm attempting to implement such a trait in clang.  I want an implementation</div>
<div>for two reasons:</div><div><br></div><div> a. I want to make sure that the trait will meet my requirements.</div><div><br></div><div> b. If I submit a follow-on paper to the C++ standard committee, I would</div><div>
    like that paper to be based on experience with an implementation.</div><div><br></div><div>I am not a compiler person, but I'm game to try hacking clang.  I've</div><div>made an initial attempt at an implementation.  I feel like my initial</div>
<div>attempt, adding a new unary trait to clang (and always passing void), is not</div><div>going well.  I've created a new unary trait that always returns false with</div><div>surprisingly little damage to the clang code base.  But I haven't yet figured</div>
<div>out how to examine the context so I know when to return true.  It also</div><div>appears that clang caches the trait result.  So, even if I solved the context</div><div>problem, once the trait is evaluated it would always return the same value,</div>
<div>regardless of each new context.</div><div><br></div><div>So I'm asking for guidance.</div><div><br></div><div>Suggestions?  Thanks in advance.</div><div><br></div><div>Scott Schurr</div><div><a href="mailto:S.Scott.Schurr@gmail.com">S.Scott.Schurr@gmail.com</a></div>
<div><br></div></div>