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

From: Douglas Gregor (gregod_at_[hidden])
Date: 2003-10-09 11:55:07

On Thursday 09 October 2003 12:25 pm, Joel de Guzman wrote:
> David Abrahams <dave_at_[hidden]> wrote:
> > *I'm* not confused.  I have no problem with the idea of having a
> > class
> >
> >   a. whose _instances_ can be used as a function which squares numbers
> >
> >   b. which is itself a metafunction class that computes the instance's
> >      return type based on the arguments passed
>
> Snips...
>
> For the record, I am not against naming it "apply". However, I am not sure
> how that will jive with Doug's uniform return type proposal. I'm sure
> we do agree that there must be one and only one way to do it.

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:

struct find_
{
  // Metafunction  class
  template<typename Sequence, typename MetaFunction>
    struct apply
    { typedef <MPL find algorithm result> type; }

  // Function object
  template<typename FunctionCall> struct result;

  template<typename F, typename InputIterator, typename T>
    struct result<F(InputIterator, InputIterator, T)>
    { typedef InputIterator type; };

  template<typename InputIterator, typename T>
    inline InputIterator 
    operator()(InputIterator first, InputIterator last, const T& x)
    {  return <standard library's find() algorithm result>; }
} find;

Perhaps I'm sticking words in everyone's mouth, but I had thought that we 
agreed on this. I believe "we" included (at least): Joel, Dave A. Jaakko, and 
Aleksey.

        Doug