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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk