Re: [boost] Re: Review Request: FC++

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-09 13:51:00

On Fri, Oct 10, 2003 at 01:54:04AM +0800, Joel de Guzman wrote:
> David Abrahams <dave_at_[hidden]> wrote:
> > Douglas Gregor <gregod_at_[hidden]> writes:
> >> We've discussed this before, although I can't find a reference to it
> >> because I believe it was an e-mail conversation.  The reason we did
> >> not name the "result" member class template "apply" is that we
> >> envisioned function "object types that were both metafunction classes
> >> and function objects, "and therefore would have both "apply" (in the
> >> MPL sense) and "result" (in the result_of sense) member class
> >> templates.  For instance:

Based on this discussion, perhaps the best choice for FC++ is...

Rather than having each functoid type being a metafunction (e.g.
"map_type" is a metafunction to compute the result type of the "map"
functoid based on its argument types), instead have either a nested
type or an external traits thingy "as_metafunction".

Yeah; this generalizes then from FC++ to everything that supports the
result_of stuff.  I'm imagining:

   // For every type F, where F supports result_of
   metafunction_result_type_computer<F>

is the corresponding metafunction which computes the result type based
on the argument types.  I think this is the most general abstraction.
So, for example,

   metafunction_result_type_computer<map_type>
      ::apply< is_even_type, list<int> >::type   ===   list<bool>

The problem, of course, is that it is not terse.  I think one of David's
original motivations was to say something shorter than

   mpl::lambda< map_type::sig<_1,_2> >::type    // or whatever

The other motivation I am working from is "uniformity" (you shouldn't
have to know that FC++ functoids use "sig", whereas other entities use
"result", ...).

One obvious thing is to rename metafunction_result_type_computer to
MRTC, so then MRTC<F> is the metafunction result type computer.  But
this obviously violates naming convention guidelines.

Hmm.  Is there some point in the design space here that optimizes all of
the various considerations?

-- 
-Brian McNamara (lorgon_at_[hidden])