Re: type traits, reflection, and whatnot

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Phil Edwards <phil@jaj.com> writes:

[...]

| In the informal discussion the Gaby mentioned (@Santa Cruz), were there
| any kinds of reflection /not/ covered by N1345 that y'all were pondering?

Robert Klarer, Judy Ward and I evaluated the proposal 

  http://anubis.dkuug.dk/JTC1/SC22/WG21/docs/papers/2002/n1381.htm

and we discussed several alternatives and recommanded rejecting some
aspects. The day that followed, I implemented a version of the
conclusions we arrived at, I had a chance to sit next to Benjamin the
day that followed, I showed him what that may looks like in practice.
(the implementation was straightforward but if we were going to have a
bunch of static_assert-like operator we rather follow a scalable
design). 

While we were looking for the restaurant (that took some time :-) we
pondered possibilities of asking whether a name was declared in a
class (be it template) or a namespace, if yes then having the list of
declarations.  I think it was mentioned that having string lierals as
valid template-arguments may be useful in this case.

I seem to recall Matt mentioned a case where determining whether a
specialization comes from a given template may be handy.

More generally, Jason expressed the desire (which was also the
sentiments we all had) of seeing more compile-time reflection in the
language. 

I also have to mention a point not discussed during that dinner but
which has been a work in progress: Constraints on template-arguments.
You may want to look at the set of slides 

http://www.codesourcery.com/publications_folder/generic-programming-in-cxx.pdf

some things are missing on those slides, many new insights have
been gained and better syntax has been designed (thanks to Bjarne
Stroustrup and many others) since then. 

I would also like to mention a work-in-progress in the Evolution Working
Group concerning "typedef template" and "template aliasing".

Notice that the notion of aligned storage (for which I made a proposal
for inclusion in V3 some time ago) also fits in this general idea of
compile-time reflection.

[...]

| I feel that it would be easier and more maintainable to implement the bulk
| of N1345 in library code, and only build special knowledge into the compiler
| of the few templates which need it.

Most of those knowledge are already in the compiler, I don't believe
in information duplication.  That does not mean I suggest
implementing everything in the compiler, just that we should be
cautious about seek for "minimalism".  For example, I would suggest
to have direct support for __is_fundamental<> in the compiler.
May people at Boost suggested that compilers "automatically
instantiate such traits templates" (something the SGI compiler is
known to do)

| I also feel it would be cleaner to
| write the library headers rom scratch rather than importing the headers
| from Boost.

Agreed. 

[...]

| Right now v3 has two different type traits schemes at work in the library.
| I've been wanting to clean them up for a long time but haven't really had
| a clue how.

I would vote for retaining bits/cpp_type_traits.h general idea for the
reasons I outlined there :-)

-- Gaby