<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 8, 2014 at 11:31 PM, Jonathan 'Rynn' Sauer <span dir="ltr"><<a href="mailto:jonathan.sauer@gmx.de" target="_blank">jonathan.sauer@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<div class=""><br>
>> FYI Stroustrup shot that feature down pretty hard<br>
> <<a href="http://isocpp.org/blog/2013/03/n3613-static-if-considered" target="_blank">http://isocpp.org/blog/2013/03/n3613-static-if-considered</a>>. It may not be<br>
> the best one to implement.<br>
><br>
> Yes, I know. But I hoped to see it like an extension. Just interesting, can<br>
> it be helpful?<br>
<br>
</div>FWIW: Clang supports Microsoft's __if_exists extension when in VisualC++ mode:<br>
<<a href="http://msdn.microsoft.com/en-us//library/x7wy9xh3.aspx" target="_blank">http://msdn.microsoft.com/en-us//library/x7wy9xh3.aspx</a>> It is similar (although<br>
more restrictive) to "static if".<br>
<br>
I'm not sure if a clang-specific language extension would be accepted into clang,<br>
although it could be used to evaluate the usefulness of "static if". But then<br>
I'm biased as I'd very much like "static if" to become part of the C++ standard;<br>
even though it's viral, as Stroustrup writes, it would reduce the need for helper<br>
templates.</blockquote><div><br></div><div>The big problem with 'static if' is that it's three different features that have got muddled together. Those are:</div><div><br></div><div>1) A static if, just like #if, where the condition must be a non-dependent constant expression, and the body can be arbitrary brace-balanced token soup. This basically just allows more advanced constants in #ifs.</div>
<div><br></div><div>constexpr bool has_interval_literals() { return __has_feature(interval_literals); }</div><div>static if (has_interval_literals) {</div><div>  static_assert( [1...4) + [4...6] == [1...6], "" );</div>
<div>}</div><div><br></div><div>2) A template if, that introduces a separately-instantiable template entity (and thus introduces a scope). As is usual for templates, the body must be instantiable for some template arguments (it can't be token soup).</div>
<div><br></div><div>3) An enable if, that makes declarations visible or invisible depending on some predicate.</div><div><br></div><div>Of these:</div><div>- the first isn't hugely useful, since a lot of the "interesting" compile time constants for this sort of check are preprocessor constant expressions too, so #if works,</div>
<div>- the second is already possible using generic lambdas (but it's a little hacky):</div><div>  if_(b, [&](auto){ blah; }, [&](auto){ blah2; }) // implementation left as an exercise to the reader</div><div>
- the third is already somewhat possible (using clang's attribute enable_if), and will be standardized through the concepts effort.</div><div><br></div><div>People sometimes want to mix these possibilities (and in particular, use the 'token soup' model in a template), but that's essentially incompatible with the tree-transformation model that is used for template instantiation by at least Clang and GCC. Given our current state, I think the only thing worth pursing is #1, and I don't think it meets Clang's criteria for language extensions.</div>
</div></div></div>