-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 May 2008 05:14 am, Johan Torp wrote:
Frank Mori Hess wrote:
I've just noticed that neither Anthony's or Braddock's future libraries seem to support construction of a future directly from a value, like
future<int> fut_int(5);
Adding such a constructor gives support for implicit conversion of a value of type T to a future<T>. So a function which takes futures as arguments can also seamlessly accept values:
future<void> my_func(future<int> f1, future<int> f2);
my_func(fut_int, 3);
Adding an explicit constructor is one thing. Allowing implicit type conversions is more dangeous and needs to be thought through carefully. Could you make do with explicit constructing?
my_func(fut_int, future<int>(3));
Can you come up with any specific examples of how implicitly constructing a ready future from a value would be dangerous? It's not like implicity constructing a shared_ptr from a raw pointer, which might cause the raw pointer to be accidentally deleted. It's certainly less dangerous than going the other direction (which has generated some controversy): implicit conversion of a future to a value, which can block. Note, I'm not suggesting adding support for direct assignment from the template type. I certainly wouldn't make the poet::future constructor explicit and diminish useability without a concrete reason for doing so. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFILZZ15vihyNWuA4URAnJIAJoDjRHtgNAAQ4Bm15AislS4kzg1tgCdG2pg DG/tpcYd4QldDsViLlL9/hw= =jdVL -----END PGP SIGNATURE-----