Re: [boost] Boost.Function const semantics

From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-07-20 15:00:51

> The final point in the "disadvantages" swayed me. I believe it would be best 
> to remove operator() completely (thereby leaving only operator() const) 
> because
> 	1) Boost.Function can be considered to be a handle or pointer to a function 
> object, so constness of Boost.Function is disjoint from constness of the 
> targetted function object.

This statement made me think about an analogy to the 
iterator/const_iterator distinction in the standard library. Perhaps 
the right distinction here is function/const_function, where 
const_function is a handle to a const function object, just as a 
const_iterator is a handle to a const iterated-over object.

This will open some different cans of worms (what conversions should be 
supplied?) but it would make the issue of stub functions go away while 
still allowing users who need const/non-const distinctions in their 
function objects to do that. And, it would allow one to use differing 
return types in the underlying function object when that is 
appropriate, I think... There still might be surprising results at 
times, if a user makes the two operator()'s have differing semantics, 
but in that case he deserves to have to think about things hard (IMHO, 
anyway). ;)

What do others think? Are there issues here that I've missed in my 
rather cursory thinking about the problem?

George Heintzelman
georgeh@