> > Agreed, except for the part about adding new features to the language.
> > For
> > example, I would imagine my interpretation would be best served by the
> > compiler making its internals available as a set of type definitions
> > in an internal namespace: let's call it __compiler_internals__.
>
> Now we're running into an ambiguity about what "the language" means.
>
> Some people (very reasonably) consider "the language" to mean "stuff the
> compiler handles". Other people (also reasonably) consider "the language"
to
> mean everything that's specified by the standard for the C++ programming
> language, including the library.

Sure, I appreciate that sentiment. However the current ISO spec is pretty
clear that the language is everything in that spec. I personally think there
is a strong case to be made that the language plus the absolute minimum
parts necessary from the library should go into one document, and the
library itself broken up into multiple other documents. And maybe that will
happen for C++17.

Until then, I'm almost certain most people joining here will think features
= library features. Why? Because runtime libraries grow far faster than
their language. And that's what appears as the complexity management problem
in most people's minds, not that the language has caused that to happen in
the first place.

Also, there's already a huge amount of feature testing of the narrow kind
you mean in the STL. Want to know the maximum size of arbitrary type T? The
STL feature detects. So long as that's compile-time available, that's fine
by me. And we might as well stick with that instead of magic intrinsics like
__cxa_has_atomic_cas() or something.

> In any event, what you're talking about is certainly new stuff that would
need to
> be provided by an implementation, which can't be used on an implementation
> that doesn't (yet) provide it. Making it possible for a program to
determine
> whether an implementation provides it (yet) is precisely what I believe
SG10 is all
> about.

Then what we really really need is the ability to introspect a namespace and
a type for what the compiler thinks it currently contains. That's SG7 really
of course. But some of the earlier posts to this mailing list get solved by
such a facility e.g. there was a request about whether a type provides
rvalue construction or not. Well, I think we can detect that right now in
present compilers via SFINAE. What we can't do is detect whether some type T
has been defined in some namespace N and then mapped using 'using' into
namespaces X, Y and Z etc. We also can't enumerate all member functions in a
type, though we can probe for known ones. The ability to enumerate a
namespace would be even better, though I can see that causing compile times
to jump (imagine iterating namespace std 2000 times per compiland).

Back to feature testing of the narrow kind you mean, I'm of the mind
currently that if you enable the programmer to test for whether the STL has
provided some class X, which is used as proxy to infer the support of some
feature Y, that is surely sufficient?

Maybe I'm completely missing the point of feature testing. Clark, you're the
recognized expert here. What am I missing?

Niall