From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2007-03-20 14:12:38
On 3/20/07, Daniel Walker <daniel.j.walker_at_[hidden]> wrote:
> On 3/20/07, Eric Niebler <eric_at_[hidden]> wrote:
> >
> > Daniel Walker wrote:
> > > On 3/20/07, Eric Niebler <eric_at_[hidden]> wrote:
> > >> Daniel Walker wrote:
> > >>> Still, for compilers that Boost.Typeof doesn't support, it would be
> > >>> nice if result_of could handle Boost.Lambda at least. More recent
> > >>> libraries and future libraries could consider adopting a previously
> > >>> existing practice (result<F(Args) or sig<tuple<Args> >) that result_of
> > >>> can support without typeof.
> > >>
> > >> IMO, you have this backwards. Rather than patch result_of to handle
> > >> lambda, lambda function objects should be modified to follow the
> > >> result_of convention. It's now standard, after all.
> > >
> > > Good point. I considered doing that, but didn't want to intrude on any
> > > user code out there that follows the current Boost.Lamda convention.
> > > Of course, I don't mind submitting a patch to Boost.Lambda as you
> > > suggest if there's interest. That would help alleviate the problem of
> > > having multiple return type conventions among Boost libraries. I could
> > > also try to patch Fusion. Perhaps, my result_of patch could still be
> > > useful for providing backwards compatibility for current Boost.Lambda
> > > style user defined functors.
> >
> >
> > 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.
gpd