type traits, reflection, and whatnot

[Phil Edwards]

On Sun, Jan 05, 2003 at 02:48:33PM +0100, Gabriel Dos Reis wrote:
> I would also like to mention a work-in-progress in the Evolution Working
> Group concerning "typedef template" and "template aliasing".

I would love to see typedef templates.


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

After sending my email, I had a go at implementing the library side of this.
It's a minor PITA to /not/ reinvent half of Boost's MPL and a chunk of
Loki on the side, just to be able to write userland code cleanly to do this.


> May people at Boost suggested that compilers "automatically
> instantiate such traits templates" (something the SGI compiler is
> known to do)

That's my feeling too.

I'm tempted to suggest that the proposed <type_traits> header look like

    // Copyright blah blah blah

    #ifndef _GLIB_the_usual
    #define _GLIB_the_usual

    #pragma GCC system_header
    #pragma GCC type_traits

    foo

    #endif

with possibly the primary template declarations where "foo" is.  The compiler
handles all the "special specializations", which I'm going to call "special
s13s" or even "ss13s" because "specializations" is getting annoying to
type out....

The win is that none of the data structures used to handle the ss13s need
to be initialized in the compiler unless we see the new pragma.  We don't
have to actually parse any of the s13s either, as we would if some of the
traits were going to be handled in library code.

The above scheme was actually what I wanted to try when I first saw N1345,
and then spent several days banging my head against parse.y.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002