From: Mat Marcus (mat-boost_at_[hidden])
Date: 2003-10-09 14:40:23
--On Thursday, October 09, 2003 2:51 PM -0400 Brian McNamara
> 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
Yes! At the risk of repating myself from the recent "Beyond Objects"
thread: Down with members, nested types and trais, in public
It's that darned OO mentality that's so hard to shake loose on the way
to generic design. Having the return type calculator as a free
metafunction seems like just the ticket.
> The problem, of course, is that it is not terse.
> Hmm. Is there some point in the design space here that optimizes
> all of the various considerations?
Hmm. Good question.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk