Re: [boost] Boost.Function variant needed

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-11-15 15:35:45

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 is more consistent for the user than having ref(x) for normal objects 
x and fref(x) for function objects... what happens in generic code when you 
don't know if you have a function object or a normal object?

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?

3) Bind/Lambda can just wrap ref(x) in their own internal ref-like classes to 
allow parameters to be ignored. 

I'm looking at "ref(x)" as essentially a directive that says "use a reference 
to x instead of copying it". Bind and Lambda have a particular view of how 
this should be done (by making it a function object that ignores its 
arguments), Function will have a different view of how this should be done 
(by storing a pointer to the underlying function object without any cloning), 
and standard algorithms would have yet a different view of how this should be 
done (the ref object acts as a pass-through function object to allow stateful 
function objects).

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

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

        Doug