Re: [boost] Re: A new boost::thread implementation?

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
reasons?

What about:

    result(f)

> 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
www.boost-consulting.com