Re: [boost] Boost.Function const semantics

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-21 23:59:04

On Saturday 21 July 2001 04:07, you wrote:
> 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)

I was proposing just:
functor => 1

and an auxiliary function object could (at 'function' 
assignment/initialization time) decide if for a particular target function 
object instance, it should be
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.

I believe the answer is "yes" that it makes sense for semantics 2 or 4, 
because a const 'function' object can't have the function object it targets 
changed. However, see the reason in my prior post why having parallel 
function/const_function won't (and probably can't) work.

> 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

Does Boost have Release Notes?

        Doug