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
> How soon do you
> think everyone will be using a C++0x compiler supporting
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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk