[cfe-dev] Clang getting involved

[Richard Smith]

On Sat, Mar 8, 2014 at 11:31 PM, Jonathan 'Rynn' Sauer <
jonathan.sauer at gmx.de> wrote:

> Hello,
>
> >> FYI Stroustrup shot that feature down pretty hard
> > <http://isocpp.org/blog/2013/03/n3613-static-if-considered>. It may not
> be
> > the best one to implement.
> >
> > Yes, I know. But I hoped to see it like an extension. Just interesting,
> can
> > it be helpful?
>
> FWIW: Clang supports Microsoft's __if_exists extension when in VisualC++
> mode:
> <http://msdn.microsoft.com/en-us//library/x7wy9xh3.aspx> It is similar
> (although
> more restrictive) to "static if".
>
> I'm not sure if a clang-specific language extension would be accepted into
> clang,
> although it could be used to evaluate the usefulness of "static if". But
> then
> I'm biased as I'd very much like "static if" to become part of the C++
> standard;
> even though it's viral, as Stroustrup writes, it would reduce the need for
> helper
> templates.


The big problem with 'static if' is that it's three different features that
have got muddled together. Those are:

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.

constexpr bool has_interval_literals() { return
__has_feature(interval_literals); }
static if (has_interval_literals) {
  static_assert( [1...4) + [4...6] == [1...6], "" );
}

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).

3) An enable if, that makes declarations visible or invisible depending on
some predicate.

Of these:
- 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,
- the second is already possible using generic lambdas (but it's a little
hacky):
  if_(b, [&](auto){ blah; }, [&](auto){ blah2; }) // implementation left as
an exercise to the reader
- the third is already somewhat possible (using clang's attribute
enable_if), and will be standardized through the concepts effort.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140309/7811ccc4/attachment.html>