> > Can I ask a stupid question?
> >
> > What are we defining as a "feature"?
>
> That's not at all a stupid question; answering that is one of the really
significant
> problems that this study group was formed to investigate.
>
> For the moment, we're just using it to mean the obvious: a new thing in a
> standard.

Y'see, personally speaking I'd be far more concerned with detecting features
of my environment than new language or library features. Which, of course,
bleeds into SG7 work. But what I mean is far more fundamental than even
reflection.

For example, I'd like the ability to examine the filing system from C++
metaprogramming, see if some file exists and if so change what I include (or
import, if SG2 comes to fruition) . I'd even like to be able to load in data
and do things to that data which is then used by the metaprogramming to
output stuff. Ideally speaking, I'd like the ability to modify the
compiler's AST from within the code being compiled itself.

In other words, think of XSLT for C++ compiler internals.

> > And should we be able to detect it at compile time, or runtime, or both?
>
> The problem is how to deal with different implementations (including
different
> compilers), some of which have a feature, and others of which do not. If
an
> implementation doesn't have a feature, a program that tries to use it
won't be
> able to build. So we're talking about detecting the presence of a feature
at
> compile time.

Ok, I appreciate that you've got a much narrower scope than I would have.
You're limiting it to things like testing for the presence of atomics
support, that sort of thing. I would, though, like to see the ability to
test for natures of things, so say does this object has string-ish nature?
That's feature testing too, albeit of a different kind.

Still though, access to the internal implementation of the compiler from the
language would be very useful. The problem is not making such support
dependent on one form of compiler implementation. We saw how the failure of
exported templates led to a huge realization of how compiler implementation
would need to evolve, and hence we now see clang/LLVM which was our
industry's response to those realisations. That said, it would be deeply
unwise to assume clang/LLVM won't cause another set of realisations of what
also needs to change, and another post-clang/LLVM approach to compiler
implementation to emerge as a result.

Niall