Re: [boost] Boost.Function variant needed

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-15 15:53:08

From: "Douglas Gregor" <gregod_at_[hidden]>
> On Thursday 15 November 2001 12:08 pm, you wrote:
> > Let me see if I understand you correctly. You are saying that operator+=
> > (and all other operators) should explicitly check for ref() and wrap it
in
> > an appropriate argument-ignoring function object.
>
> Yes.
>
> > A possible approach. What are its advantages?
>
> 1) Allows the capabilities we would want from "fref(x)" to be part of
ref(x),
> so, e.g., we could have:
>   std::find_if(v.begin(), v.end(), ref(stateful_function_object));

This was my original idea, too. I even expected it to work as-is but,
unfortunately, ref(f)(x) doesn't invoke the conversion operator.

>   This is more consistent for the user than having ref(x) for normal
objects
> x and fref(x) for function objects...

True.

> what happens in generic code when you
> don't know if you have a function object or a normal object?

Example, please? ;-)

> 2) ref(x) would have semantics that make sense when not considering the
> implementation of the Lambda library. Does ref(x)(5, 3.13159) returning x
> really make sense if you don't know the implementation details of Lambda
or
> Bind?

Yes. Implementation details do not matter. In Lambda, ref(x) is specified to
do just that, for consistency. All that Lambda does is create function
objects according to some simple rules.

And no, if you don't care about how Lambda views the world.

> > This doesn't really fit the current Lambda (and Bind) spirit. Since the
> > argument list is not specified,
> [snip]
> > So lambda expressions don't have arity. They act on arbitrary argument
> > tuples. That's why ref(x) can take any arguments.
>
> That strikes me as wrong from a theoretical standpoint. Say I have some
> pseudo-C++ code:
>
> struct negate {
>   template<typename T> typeof(-T()) operator()(const T&) { return -T; }
> };
>
> Now if I have an object "op" of type negate, and I have the Lambda object
> -_1, it seems wrong that op(a, b) is ill-formed whereas (-_1)(a, b) is -a.
We
> shouldn't lose the arity constraint just because we're using Lambda.

Please propose how would you compose

lambda(x, y) { return -x; }

while maintaining arity.

> > Note that I don't have a vested interest in this matter; I'm simply
trying
> > to keep ref/bind compatible with LL hoping that people will painlessly
> > transition to LL when its time comes.
>
> I'd also like LL to integrate smoothly when it's ready, but I think ref(x)
is
> a great directive to use and I'd rather not see its scope limited by any
> library.

I think that you'd need to argue with Gary and Jaakko directly. Bind is not
affected. It's special-cased for ref's. It's just that I considered their
viewpoint when I thought about adding the forwarding operators to ref and
decided against doing so.

--
Peter Dimov
Multi Media Ltd.