|
Boost : |
From: Eric Niebler (eric_at_[hidden])
Date: 2007-03-20 17:00:00
Giovanni Piero Deretta wrote:
> On 3/20/07, Daniel Walker <daniel.j.walker_at_[hidden]> wrote:
>> On 3/20/07, Eric Niebler <eric_at_[hidden]> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk