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
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,
::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
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])
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk