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.

Doug Gregor wrote:

On Nov 4, 2004, at 1:49 PM, Peter Dimov wrote:

...

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.

As do I, but I'm sure we disagree :)

I don't really understand why it's so important for function<> to be a drop-in replacement for function pointers. I have never needed to migrate code from function pointers to function<> (but I did migrate code back.)

Just dropping operator=(const result_type&) and function(const result_type&) into function would work, but changes the meaning of some existing code:

function<int()> f; f = 0;

I don't think we can do that.

We can't. :-( Lack of nullptr strikes again. (Reminds me of the "you probably can, but you may not" joke.)

David Abrahams wrote:

"Peter Dimov" <pdimov@mmltd.net> writes:

...

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?

By the same token, one could argue that this functionality ought to be pushed into boost::bind.

I'm not sure what you mean. What functionality ought to be pushed into boost::bind?

David Abrahams wrote:

"Peter Dimov" <pdimov@mmltd.net> writes:

...

David Abrahams wrote:

...

"Peter Dimov" <pdimov@mmltd.net> writes:

...

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?

By the same token, one could argue that this functionality ought to be pushed into boost::bind.

I'm not sure what you mean. What functionality ought to be pushed into boost::bind?

The ability to build an always(whatever) function object:

f = boost::bind(t);

This is not an improvement over f = constant( t ); It still needs a glue call. Also, it doesn't make much sense to use boost::bind for this functionality, because constants do not have any arguments that could be bound. The bind way to make a constant is bind( identity<T>(), t ). The original motivating example is this: struct button { boost::function<bool()> is_enabled; }; bool sometimes(); int main() { button b; b.is_enabled = true; b.is_enabled = false; b.is_enabled = sometimes; } I don't want the simple syntax to be encumbered by constant() or bind().

Aleksey Gurtovoy wrote:

How about

function_property< boost::function<bool()> > is_enabled;

or

function_property<bool()> is_enabled;

or even

property<bool()> is_enabled;

FWIW, I went with inline bool true_ { return true; } inline bool false_ { return false; } which allows is_enabled = true_; I don't like the word "property", or the property-based style of programming, in general. :-) As a side benefit, false_ comes in handy for on_click, too (which is a function<void()>). One other observation: keeping a function<> always initialized with the appropriate default (a variation of the Null Object pattern) leads to much cleaner code.