Giovanni Piero Deretta wrote:
On 3/20/07, Daniel Walker <daniel.j.walker@gmail.com> wrote:
On 3/20/07, Eric Niebler <eric@boost-consulting.com> wrote:
If lambda functors had both sig<> and result<> nested templates, then it would Just Work without causing any back-compat problems.
That's true, but I was concerned about funtors defined by lambda users. Currently, if a user wants to write a functor to be used in a lambda expression, the user needs to supply a sig<> to tell lambda what the functor's return type is.
Of course, users currently can't use these functors with result_of anyway. So, I suppose no one's feelings will be hurt if result_of doesn't support their current lambda compatible functors. And it's not too imposing to demand that they modify their functors to conform to the result_of standard, so long as they can still be used in lambda expressions. I think I'll try to patch lambda. Thanks!
What about doing both? Result_of would implement (maybe undocumented and deprecated) sig support. Lambda would implement and document both result and sig, deprecating the latter. In a release or two, both lambda and result_of would drop sig support. The users should have plenty of time for updating their code.
I'm not sure this is a good idea. I haven't looked at the patch to mpl's has_xxx code to make it detected nested class templates, but I wonder how portable it is to older compilers. I know from experience how finicky the result_of implementation is, and getting this to work on all the compilers result_of currently works on would be a difficult (impossible?) task. I'm willing to be proved wrong, however. -- Eric Niebler Boost Consulting www.boost-consulting.com