Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-02-10 08:41:40

"Peter Dimov" <pdimov_at_[hidden]> writes:

> David Abrahams wrote:
>> "William E. Kempf" <wekempf_at_[hidden]> writes:
>>> David Abrahams said:
>>>> No, my fault. Syntactically, I should've written this:
>>>> async_call<int> f(create_thread(), bind(g,1,2));
>>>> int r = f();
>>> Do you want it to be "int r = f();" or just "int r = f;" or even
>>> "int r = f.result();" or similar?
>> My other message makes it clear (I hope) that I want what I wrote
>> above.
> Are you sure that you really want the above? Or are you speculating that you
> might want something like the above in a hypothetical situation that you
> haven't encountered yet but you might in the future?


OK, you caught me out. It's the latter.

>>> The f() syntax makes it look like you're invoking the call at that
>>> point, when in reality the call was invoked in the construction of
>>> f.
>> You're just invoking a function to get the result. f itself is not
>> the result, so I don't want to use implicit conversion, and f.result()
>> does not let f behave polymorphically in a functional programming
>> context.
> f does not behave polymorphically, or rather, its polymorphic behavior isn't
> useful. In the generic contexts I'm familiar with, generators are only used
> to produce a sequence of values.
> I am not saying that this is never useful, but syntax should target the
> typical scenario, not corner cases.

Agreed. I suppose that you'll say it doesn't target the typical
scenario because of its confusability. I wouldn't argue. Any other

What about:


> It makes a lot more sense (to me) to reserve operator() for the Runnable
> concept, since that's what Boost.Threads currently uses.

And prevent any other concepts from using operator()? Surely you
don't mean that.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at