I think Niall's point is that it's harder for the wrapper to know whether it's going to be called a single time or multiple times for a given precondition future, so it's safest if that is accepted only as a shared_future.
It's more that when shared_future can only EVER refer to a shared_ptrafio::handle all of which is thread safe, I see little risk to defaulting to shared_future. What does one lose?
You lose the possibility to express your intent. There is no conceptual need in having shared ownership. The need is imposed by the bad design of the API.
I suppose arguably the wrappers could be templated to accept either future or shared_future, which might mitigate that. But perhaps there are reasons why that's undesirable as well.
The wrappers can do either without a problem because in Boost.Monad/Outcome an extension allows consuming futures to accept any number of continuations. So from my perspective, it's six of one and half a dozen of the other from an implementation viewpoint. The real question is which makes for a better library use experience, and just because a design "should" be some way or other just because theory says so and you are wilfully ignorant of the problem domain being solved isn't useful to me.
Being willfully ignorant of rules of good design isn't useful to your users either. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu