Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2007-03-23 00:38:13

on Thu Mar 22 2007, "Daniel Walker" <> wrote:

>> However, I think the solution is in the lambda library already:
> 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?

> 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.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at