[boost] Re: Review Request: FC++

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-10 11:32:41

Mat Marcus <mat-boost_at_[hidden]> writes:

>> I think it's silly to externalize everything, and (meta)functions are
>> the kind of tiny single-purpose objects which can be allowed to have
>> constraints.  Otherwise, why constrain your meta_apply either?  And
>> then, how do you invoke it?
>
> Same question as above. If I believe that the ::type/::value idiom is
> sufficiently entrenched then I might argue that requiring the nested
> type is appropriate. However if I wanted to allow a broader set of
> models that might happen to us other names (RET, result_of, sig?) then
> maybe I would prefer that the concept was defined in terms of 

What is:

> a pay as you go specializable free metafunction with a well-defined
> calling convention. 

??

> This is essentially the same as the call() question above but at
> compile time. I think that a nested apply is not used as widely.

It's true that there are two metafunction concepts:

Metafunction: a class template taking only type parameters and having
a nested ::type type.

Metafunction Class: a class having a publicly-accessible nested
Metafunction called "apply".

And it's also true that Metafunction is the more-fundamental of the
two.

So you could redefine Metafunction Class in terms of the "mpl::apply"
Metafunction.  However, you can't redefine Metafunction in terms of
any other Metafunction or you have infinite recursion.  That's my
point.

Also, although Metafunction is more fundamental, it requires more
infrastructure (lambda) to do higher-order functional programming with
it.  A metafunction class can be passed to a metafunction directly.  I
believe there *may* be good efficiency reason to preserve its current
definition.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com