"Peter Dimov" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> "William E. Kempf" <[EMAIL PROTECTED]> 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
