Re: [boost] [parameter] Lazy binding and operator|| patch

From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2007-03-27 18:18:53

On 3/23/07, David Abrahams <dave_at_[hidden]> wrote:
>
> on Thu Mar 22 2007, "Daniel Walker" <daniel.j.walker-AT-gmail.com> wrote:
>
> >> However, I think the solution is in the lambda library already:
> >> http://boost.org/doc/html/lambda/le_in_details.html#lambda.unlambda
> >
> > Really, users just need to provide a result_of compatible function
> > object. So if the documentation says that more clearly and replaces
> > the lambda example with a bind example, it would alleviate confusion.
> >
> > Unlambda gets rid of the operator|| overload resolution problem, but
> > doesn't generate a lambda compatible functor as far as I know... at
> > least not yet.
> >
> > For 1.34, since users can't use lambda anyway (due to lack of
> > result_of compatibility)
>
> I don't get it.  As mentioned earlier, we automatedly test our
> examples and that one passed.  Any idea why?

I looked in boost/libs/parameter/test and grep lambda returned
nothing. I found three tests for lazy binding with operator|| and none
used lambda. It looks like lambda was never test. Is there some other
way it would have been tested that I'm missing?

>
> > there's no need for this patch or renaming
> > op||. In the future, if/when lambda is result_of compatible,
> > keyword::operator|| will need to be renamed or somthing like this
> > patch should be applied. My preference is to keep the current syntax.
> > I kind of like using args[ _arg || default() ] better than args[
> > _arg.lazy(default()) ], especially if there's still args[ _arg |
> > default() ].
> >
> >>
> >> > And possibly change the docs to not use Boost.Lambda. We're going to
> >> > hit the same problem with the every lambda library. Changing the
> >> > implementation is to late for 1.34, but we should probably change
> >> > the docs so they don't mention Lambda. The example would become:
> >> >
> >> >   bind(std::plus<std::string>(), ref(s1), ref(s2))
> >> >
> >> > it's unfortunate, but not that bad IMO.
> >>
> >> Is it better not to discuss lambda, or to mention unlambda as a way
> >> around this problem?
> >
> > For 1.34, yes, I think it's better not to mention it.
>
> I'm open to whatever you and Daniel agree on.

I like the idea of replacing the lambda example with a boost::bind
example as Daniel suggested above.

Daniel Walker