From: David Abrahams (dave_at_[hidden])
Date: 2007-03-23 00:38:13
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:
> 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 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