"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