Re: [boost] Updated version of futures library

From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2008-06-01 20:41:14

> > What's the difference between treating a future as a placeholder and
> > having a future implicitly convertibly to its result type? Doesn't a
> > placeholder imply having this implicit conversion?
> 
> Yes, that's why I added it.  I just think it's a little dangerous (see
> following paragraph).  For example, boost::optional is a stand-in for
> its templated type, but it only supports implicit conversion from T to
> optional<T>, and not from optional<T> to T.  Maybe a future_value
> should do the same.

That's exactly my point! For this reason I don't think having the default
implicit conversion operator for futures is a good idea. But I'm starting to
repeat myself. I so won't comment any further on this thread.

> > > 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.
> 
> > And just compare the amount of code needed to write something
> > equivalent to (f1 || f2) && f3 using the proposed API from the link
> > you gave me above. That's really appalling - certainly only IMHO!
> 
> I guess you're talking about Johan's initial proposal?  In my current
> code, that is roughly
> 
> future_select(future_barrier(f1, f2), f3)
> 
> although that particular expression would produce a future<void>
> instead of a
> 
> future<tuple<variant<T1, T2>, T3>
> 
> If the user wanted composing functions or operators that returned
> tuples/variants, they could implement them without much trouble using
> future_combining_barrier.  Unfortunately, I don't have any
> documentation or the latest version of my code online yet, but
> hopefully next week.

That's better than the initial proposal but still much more complicated than
it could be: (f1 || f2) && f3. Just think about more complex logical
execution constraints, these won't be readable anymore when using the
function based syntax. Why do you object against using such a simple syntax,
even if it's now obvious that it has additional advantages over your
function based proposal (coherent return value treatment)? 

But again: I'm repeating myself, so there won't be any further comments from
my side. If the authors of the future Boost futures library object against
providing the logical operators it will be easy enough for me to implement
those solely on top of the library... This is no reason for me to vote
against it. 

But I will vote against a library implementing implicit conversion to the
result type of the future: future<T> to T.

Thanks for the insightful discussion.
Regards Hartmut