[boost] Boost.Function const semantics

From: Ronald Garcia (garcia_at_[hidden])
Date: 2001-07-21 15:07:47

Douglas Gregor writes:
 > 
 > Boost.Function is a set of function object wrappers for deferred calls. 
 > Should the function call operator be const, non-const, or should both be 
 > supplied? 
 > 
Ahh.  I've been dealing with this issue in the design of my
Boost.MultiArray candidate. 

 > 	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, to me, is the most important part, and has been often confusing
in figuring out the proper semantics for library-defined
types that attempt to mimic pointer/reference semantics.  If we take
the analogy of a "pointer to functor", you're fighting with the difference
between:

1) functor * p;
2) functor const * p;
3) functor * const p;
4) functor const * const p;

your current semantics seem to have (=> meaning "is analogous to"):
 functor => 1)
 const functor => 4)

while the proposed semantics seem to be:
 functor => 1)
 const functor => 3)

One pertinent question is, is there a sensible use for a functor with
semantics 2) or 4).  That is, does it make sense to have a functor
that itself has constness regardless of the constness of that to which
it refers.  If the answer is yes, it may be necessary to have a
parallel set of types const_functor to go with functor.  That way,
functor will be call operator(), and const_functor will call
operator() const.  I think for these purposes, a function pointer
could be considered operator() const.  Then, functor could be
converted to const_functor but NOT vice-versa. 

As far as making the semantic change, I vote for doing so.  While
Boost.Function is already "out there", I think that the current
semantics confusing.  If/When these changes are released, A notice
should go in the Boost Release notes stressing such a semantic
change. 

ron