Re: [boost] Updated version of futures library

From: Frank Mori Hess (fmhess_at_[hidden])
Date: 2008-05-31 23:21:12

On Saturday 31 May 2008 21:19, Hartmut Kaiser wrote:
> I'm perfectly aware of this. And actually I expressed exactly the same
> by pointing out the main difference between the two sets of operators:
> the logical operators I proposed are for the futures themselves while
> the others are related to the future results.
>
> But you're diligently ignoring my point: overloading the operators for
> the future results is conceptually equivalent to having a default
> conversion operator to the result type for the future itself! And for
> that reason I would not like to see something like that in the future
> library.

Ah, I think I'm understanding you better now.  You are appalled by the idea 
of treating a future<T> like it was a T, is that correct?  You want a 
future<T> to only be treated like an abstract handle to a value, not the 
value itself?  I wasn't ignoring your point, it's just that your view is 
extremely foreign to how I view futures, so your words were almost 
meaningless to me.  I view being able to view a future<T> as a placeholder 
for a T object as a large part of what makes futures useful.  I 
implemented the future class in libpoet to support that, with implicit 
conversions from future<T> to future<U>, from T to future<T>, etc.  And 
being able to treat a future<T> as a placeholder for a T is essential to 
implementing things like poet::active_function.  

I don't particularly like the implicit conversion from T to future<T>, but 
that has absolutely nothing to do with not wanting to treat a future<T> as 
a placeholder.  It's simply because the conversion can block, and thus 
produce unexpected behavior (an object appearing on the right hand side of 
an assignment stalling your program).  The explicit future::get() at least 
gives a hint that something more than a quick conversion might be 
happening.

I guess the features that allow a future to act as a placeholder could be 
split out into a separate higher level class, call it "future_value", 
which would internally contain a plain old future.  The idea doesn't 
really do anything for me, but maybe you would find it preferable?

> OTOH, IMHO, having the logical operators alone improves code
> readability, simplifies the implementation (by avoiding multiple
> overloads for different parameter counts), allows to build more complex
> logical execution restrictions as (f1 || f2) && f3 (which is not
> possible using the proposed wait_for_all and wait_for_any), and all that
> without having to sacrifice any of the existing functionality.

The 
poet::future_barrier/future_composing_barrier/future_select/future_selector 
stuff I'm currently working on allows for composition.  Did you see the 
earlier discussion on this a couple weeks ago?  For example this thread:

http://lists.boost.org/Archives/boost/2008/05/137417.php

>
> > Personally, I don't particularly want to see a future
> > library overload any logical operators at all, or at least have the
> > overloads sequestered in separate headers that aren't included by any
> > of the other future library headers.
>
> That's a matter of taste, for sure. But would you mind telling us why
> you don't want to have these? Your opinion sounds to be quite strong, so
> you must have good reasons!

It's the obvious reason.  I don't think taking a function with a 2 letter 
name, which is already overloaded, and adding a new set of overloads to it 
which have semantics completely unrelated to the existing overloads is a 
desirable or aesthetically pleasing interface.  No one would even consider 
doing such a thing if the function wasn't an operator.  I guess I just 
don't find operator syntax as compelling a feature as others.