Re: [boost] boost::function feature request?

From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-11-04 13:49:02

Aleksey Gurtovoy wrote:
> Peter Dimov writes:
>> When using boost::function<bool()> to implement event callbacks such
>> as is_visible or is_enabled, it's very convenient to pass 'true' or
>> 'false' directly, instead of going through bind( identity<bool>(),
>> true ). An UI button I recently did even had separate bool
>> properties in addition to the callback events for these reasons.
>>
>> I wonder whether it's reasonable to add
>>
>>     this_type& operator=( T const & t );
>>
>> to function<T()> that does the obvious thing.
>>
>> Of course f = t; is merely a shorthand way of spelling f =
>> boost::lambda::constant(t), but a dependency on lambda isn't always
>> desirable.
>>
>> Thoughts?
>
> http://thread.gmane.org/gmane.comp.lib.boost.devel/76774
> http://thread.gmane.org/gmane.comp.lib.boost.devel/76778
> http://thread.gmane.org/gmane.comp.lib.boost.devel/76784
>
> I ended up with 'f = always( whatever )',

What an amazing coincidence. :-)

> which grew on me to the point that I don't wish for the above anymore.

Well, I still do. is_enabled( true ) is much better than is_enabled( 
always(true) ). _I_ can handle either syntax, but other programmers find the 
former much more accessible.

The =0 collision didn't occur to me, mostly because I've never treated 
boost::function as a function pointer. I know which feature I'd prefer if 
given the choice.

I'm not sure what Doug had in mind when he said that it would be 
unimplementable, as the scalar constructor and the scalar assignment are not 
templates.

However, now that I think about it, I could just define true_ and false_ 
function objects. This doesn't solve the general problem but it'd get the 
job done in this specific case.