This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

1048. Provide empty-state inspection for std::unique_future

Section: 32.10.7 [futures.unique.future] Status: Resolved Submitter: Alisdair Meredith Opened: 2009-03-12 Last modified: 2021-06-06

Priority: Not Prioritized

View all other issues in [futures.unique.future].

View all issues with Resolved status.

Discussion:

Addresses UK 335 [CD1]

std::unique_future is MoveConstructible, so you can transfer the association with an asynchronous result from one instance to another. However, there is no way to determine whether or not an instance has been moved from, and therefore whether or not it is safe to wait for it.

std::promise<int> p;
std::unique_future<int> uf(p.get_future());
std::unique_future<int> uf2(std::move(uf));
uf.wait(); // oops, uf has no result to wait for. 

Suggest we add a waitable() function to unique_future (and shared_future) akin to std::thread::joinable(), which returns true if there is an associated result to wait for (whether or not it is ready).

Then we can say:

if(uf.waitable()) uf.wait();

[ Summit: ]

Create an issue. Requires input from Howard. Probably NAD.

[ Post Summit, Howard throws in his two cents: ]

Here is a copy/paste of my last prototype of unique_future which was several years ago. At that time I was calling unique_future future:

template <class R>
class future
{
public:
    typedef R result_type;
private:
    future(const future&);// = delete;
    future& operator=(const future&);// = delete;

    template <class R1, class F1> friend class prommise;
public:
    future();
    ~future();

    future(future&& f);
    future& operator=(future&& f);

    void swap(future&& f);

    bool joinable() const;
    bool is_normal() const;
    bool is_exceptional() const;
    bool is_ready() const;

    R get();

    void join();
    template <class ElapsedTime>
        bool timed_join(const ElapsedTime&);
};

shared_future had a similar interface. I intentionally reused the thread interface where possible to lessen the learning curve std::lib clients will be faced with.

[ 2009-10 Santa Cruz: ]

NAD EditorialResolved. Addressed by N2997.

Proposed resolution: