Re: [boost] Updated version of futures library

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-05-31 21:19:22

Frank Mori Hess wrote:

> > > > > would be false and otherwise the composed future would not be
> > > > > ready yet.
> > > >
> > > > Doing it the way you're proposing implies shortcutting
> > > > operator&&(), which can't be implemented.
> > >
> > > left-to right evaluation can't be short-circuited, but he's talking
> >
> > Right, that's exactly my point.
> >
> > > about short circuiting in time, as either the lhs or rhs futures
> > > complete.
> >
> > Didn't we talk about operator&&()? No 'either/or' here, only both
> > futures. Additionally, the same comments apply as outlined below.
> 
> I'm pretty sure he's not talking about your "wait_for_all" operator&&()
> at all, he's talking about one with semantics closer to the "real"
> operator&& defined by the language.

Sure, I understand. But the issue is that these are very similar to the
proposed math operators in the sense that they add semantics in terms of the
future results not the futures themselves.

> > My main point was that such operator overloads apply to the result
> > types and not the futures themselves, which adds unnecessary
> semantics
> > and defeats separation of concerns. And, BTW, this is very much like
> > the default conversion operator to the result type for the futures
> > which - as most have agreed - is a bad idea.
> 
> It only appears to defeat "separation of concerns" because you're not
> separating your definition of the future logical operator overloads
> from his.  

This is just wrong and I don't think I gave you any reason to assert this.
Please refrain from imposing something I didn't say just for the sake of
making your point.

> They really are two different ideas and are not useful for
> the same things.  

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.

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.

> 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!

Regards Hartmut