|
|
Threads-Devel : |
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2008-03-13 14:49:14
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 13 March 2008 14:04 pm, Anthony Williams wrote:
> That's what I expected. It just feels wrong to me to provide a
> future<Y> that actually does Y(X(W(V(some_u)))) when you get a value
> from it. You could end up having a future<double> that does
> (double)(int)(some_double), thus truncating the initial value, and
> this isn't apparent from what you've got.
That's not a bug, it's a feature :) Isn't it the same behavior and just as
apparent as doing conversions with wrapped values directly?
double u = 1.5;
int v = u;
double w = v;
Any C programmer would naturally expect w to be 1.0. I would expect the same
behavior with analogous futures code. Indeed, if I created a future<double>
from a future<int> and didn't did't receive an integer value from it (because
somewhere down the line the future<int> lead to a promise<double>), I'd be
quite surprised.
I suppose this boils down to the fact that in most implementations multiple
copies of a future (with the same type) will all be equivalent shallow copies
looking at the same promise for their value. But as a user, I also want to
think of a future<T> as a placeholder for a value of type T, and have its
assignment operator semantics be deep-copy (make the future<T> act as much
like a T value as possible). The shallow-copy implementation for futures
with identical types is just an implementation optimization to me.
- --
Frank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFH2Xcr5vihyNWuA4URAuALAKC5cZlGsC7y7VTlX9yWmmx6Fc9D8wCgoGA9
gmhNmm70dJqYfh7oPXuh0zE=
=jf/H
-----END PGP SIGNATURE-----