Re: [boost] bind/lambda/phoenix and result_of

From: Andy Little (andy_at_[hidden])
Date: 2006-05-10 21:10:10

"David Abrahams" wrote
> "Andy Little"  writes:
>
>>>>> I can't ask my library's users to register types.
>>>>
>>>> Why not?  We all want decltype and auto in the language dont we?
>>>> BOOST_TYPEOF is the closest we have. Show your users how to use it
>>>> while we wait for language support.
>>>
>>> Because I want to serve my users, not force them to learn about an
>>> interim solution that they won't need when the real feature comes out.
>>
>> Not long to wait then, assuming upgrading is viable.... ;-)
>
> Should I assume you're just baiting me, or what?

I'm just exasperated. You seem to have completely reversed your position from
previous discussions. For example see the "result_ofOp, operator should be a
template parameter"," [typeof][result_of] Separated at Birth" threads on this
newsgroup.

> How soon do you
> think everyone will be using a C++0x compiler supporting
> auto/decltype?

I think it will be (say) 5 years or more? My opinion (but I am sure not an
expert so may have this totally wrong) is that compiler implementors are more
likely to incorporate the decltype/ auto functionality sooner if a substitute
such as Boost.Typeof is being widely used. (Maybe the GNU guys will also get
around to sorting out the problems with
expressions in return types)  The alternative using result_of(Op(...) ) seems to
show the opposite, that we really dont need that functionality in the language,
so why bother implementing it? That sums up what Boost.Typeof is about to me and
I am really looking forward to seeing it as part of the boost distribution. I
know it will cause problems ( error messages and registration) but I believe
that we need to face up to that  and learn/teach how to use Boost.Typeof as a
precursor to getting language support ( and in many cases the Boost.Typeof macro
does already or can be upgraded to something like  the correct functionality
without code changes)  rather than creating yet more  return type deduction
mechanisms.

[..]

> And anyway, as I've been saying, I'm *not talking about deducing the
> return type of an invoked lambda expression*.  I'm just trying to
> capture the function type.  Maybe Boost.Typeof is actually enough for
> that job; I don't know.

Right.  Sorry, the  examples of the OP sure looked like return type deduction
to me:

"
For lambda, I guess we could do something like this:

   result_of<minus_(int, _1_)>::type f = 3 - _1;
"

 f is a functor here, isnt it? Assuming lambda and the type of _1 were
registered, wouldnt Boost.Typeof give the correct result in this case? If it
does then one watered down alternative might be to provide the typeof
functionality as a
non-default option I guess.

regards
Andy Little