Interesting. Despite the fact that the problems you and I are considering can be described in (a very few) similar words, there's actually no technical commonality between them.

You want to add features to the language so programs can adapt to the environment in interesting ways.

On the other hand, I want to enable programs to adapt to different implementations with different features -- very specifically without adding any new features to the language, so this adaptation can work even with implementations that already exist today.

Clark

> -----Original Message-----
> From: features-bounces_at_[hidden] [mailto:features-bounces_at_open-
> std.org] On Behalf Of Niall Douglas
> Sent: Friday, January 25, 2013 10:54 AM
> To: features_at_[hidden]
> Subject: Re: [SG10] Should there be feature-testing for library
> features?
>
> > > 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