Re: [boost] Formal Review Announcement: Lambda Library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-08 11:50:45

From: "Jaakko Jarvi" <jajarvi_at_[hidden]>
> > * 8.2.1: I consider this a minor incompatibility with a simple
workaround. I
> > can't change Bind to match Lambda because Bind has much simpler type
> > deduction and cannot infer the return type when the function object is a
> > nested bind.
> What is your opinion about the semantics?

I'm not sure... I'd say it's about 60/40 in favor of the Bind behavior, but
neither is "right" since some people will always expect the opposite.

The "Bind way" to evaluate the first argument is

bind(apply<R>(), _1, _2);

where apply(f, a1, ..., aN) returns f(a1, ..., aN). (In
boost/bind/apply.hpp.)

With a better return type deduction probably bind(apply, _1, _2) can
suffice. This will work with Lambda as well. I've added a protect() facility
as well in boost/bind/protect.hpp, but it seems that the Lambda protect is
different and the 'right' protect is called unlambda now. :-)

> The rationale behind the choise made in BLL was, that I'd think
> many would find code like this
>
> int foo(int);
> foo(1, 2);
>
> not failing at compile time, but rather calling foo(1), unsafe.

bind(foo, 1, 2) will fail. bind(foo, _1)(1, 2) will succeed. There is a
difference between the two; the first is a common error and is detected (at
'bind time', i.e. even without a call) but the latter is, at least in my
experience, usually deliberate and rarely accidental.

> > I consider Bind's ability to ignore input arguments (regardless of their
> > placement) important, since it directly supports one of its uses: a
> > "signature adaptor." Often, you have a boost::function<> with a specific
> > signature and a concrete function that is almost compatible with it,
except
> > that it doesn't need the third function<> argument, has the first and
the
> > second reversed, and needs zero for its third. bind(f, _2, _1, 0) and
you're
> > done.
>
> I'm not sure I understood this right, but the way to write this in BLL
> would be:
>
> _3, bind(f, _2, _1, 0)
>
> Now it's explicit that this is a three argument function, the left hand
> argument of comma does nothing, the result is the right hand side of
> comma.

Yes, I know about the workaround. It works. My opinion is simply that the
strict checking doesn't buy enough safety (if any; I've yet to make a
mistake that it would've prevented) to offset the cost.

> > In other news, I've updated Bind in the CVS to use inline functions as
> > placeholders.
>
> Do you mean _1(), or the function pointer trick?

The function pointer trick. I'm sure that SunCC, HP aCC et al will have
something to say about it, though. :-)