[boost] Re: call_traits/type_traits

From: Howard Hinnant (hinnant_at_[hidden])
Date: 1999-12-10 18:06:03

Beman Dawes wrote on 12/10/99 5:23 PM
>Howard, John, Steve,
>
>I lost track of the call_traits/type_traits discussion.  Was any
>conclusion reached?  Could someone summarize where we stand?

My day job became urgent and I've had to drop work on it.  But the 
interest is still there.  Maybe over the weekend...

My view of where we stand:
--------------------------

Steve proposed a bunch of separate classes that look promising (at least 
to me) as a replacement for type_traits.  It's unclear at this point if 
Steve's submission is a subset, superset or whatever of what we want.  A 
major technical roadblock is not being able differentiate enums from 
classes from unions (especially the enum part, I could probably live with 
classes and unions being indistinguishable).  Still, even without the 
enum ability, the package looks very good.  Lightyears ahead of where we 
are without such support.  I'll refer to this set of classes as "the 
fundamentals" instead of type_traits.

call_traits (imo) can be easily implemted in terms of "the fundamentals" 
without the need to have an explicit list of built in types.  My opinion 
on the interface of call_traits stands at:

template <typename T, possibly defaulted args to help implement>
struct call_traits
{
        typedef        value_type;
        typedef        reference;
        typedef        const_reference;
        typedef        param_type;
};

value_type is essentially Steve's remove_reference.
reference is esstentially Steve's add_reference.

I believe array types are exceptions to the above two statements.

param_type is typically set to one of the other three typedefs, depending 
upon the type.

Lacking from the original call_traits proposal was the ability to handle 
cv-qualified types.  With Steve's fundamentals, this should be no problem 
(but I haven't done the work).

What this means to me:
----------------------

While the fundamentals are big unknown for me right now, call_traits 
isn't as I've implemented it without help of the fundamentals and have 
discovered it much more than mildly useful.  (The implementation is a 
giant pain in the a** that proper fundamentals should relieve).

I've used call_traits and fundamentals/type_traits to work over 
empty_member, which I now call compressed_pair in my own code.  
compressed_pair depends critically upon call_traits as I've expressed it 
above.  It acts just like pair except that it will optimize empty 
members.  Members of compressed_pair can be classes or built-in types, 
but not enums (currently).

I've built alloc_ptr on top of compressed_pair and call_traits.  It's 
auto_ptr on steroids and I'm really excited about it.

I'm currently building a hash container (my day job, finally!) which is 
making extensive use of alloc_ptr, compressed_pair, and probably 
call_traits.

So I'm fairly dug in on (the interface of) call_traits, but not 
ironically type_traits (the fundamentals).  The only stuff I have that 
depends upon the interface of the fundamentals is call_traits and 
compressed_pair, and in each case those dependencies are implementation 
details that can easily be changed.

My being dug in on call_traits doesn't necessarily mean it is the final 
word for Boost.  I say it more to express that the above interface is 
being heavily used in my current development, and proving itself nicely.

>It would be a shame to let this discussion just die; we have seen a
>lot of good ideas and need to synthesize them into an actual boost
>library everybody can feel good about supporting.

Agreed 100%.

Before call_traits is set in stone, I think the fundamentals need to be 
worked out.  They would seem to be very useful for the implementation of 
call_traits.

-Howard