N2888: Moving Futures - Proposed Wording for UK comments 335, 336, 337 and 338

Moving std::unique_future<>

In the current working draft (N2857), std::unique_future<> is MoveConstructible but not MoveAssignable. This is a strange state of affairs that leads to bizarre consequences. For example, you can move from an instance of std::unique_future<>, leaving an empty shell, but not move into an instance to provide meaningful operations. e.g.

std::unique_future<int> make_future();

void foo()
{
    std::unique_future<int> f1(make_future());
    std::unique_future<int> f2(std::move(f1)); // OK, f1 now useless
    f1=make_future(); // Error, no move-assignment operator
}

Containers of std::unique_future<>

The fact that std::unique_future<> is MoveConstructible means that you can store instances in a container such as std::vector<>, but this container is severely limited. For example, you can call push_back on a std::vector<std::unique_future<int>>, but not insert, and you can delete elements from the end by using pop_back, but not by calling erase.

void bar()
{
    std::vector<unique_future<int>> vec;
    vec.push_back(make_future());        // OK
    vec.insert(vec.end(),make_future()); // error, requires MoveAssignable
    vec.pop_back();                      // OK
    vec.erase(vec.begin());              // error, requires MoveAssignable
}

Use of futures with standard containers is an important feature. An algorithm written to make use of multiple threads might well divide its work into multiple sub-tasks, and store a std::unique_future<> for each in some form of container. Making it easy to manipulate this container is very important for this primary use case.

As an aside, it is worth noting that since std::unique_future<> is MoveConstructible, you can emulate move-assignment with destruction and move-construction:

template<typename T>
void move_assign(std::unique_future<T> & target,
                 std::unique_future<T> && source)
{
    target.˜std::unique_future<T>();
    new (&target) std::unique_future<T>(std::move(source));
}

You can even write a concept_map that does this for particular instantiations of std::unique_future<UserDefinedType>, though the standard prohibits you from doing this for instantiations that don't involve a user-defined type:

struct MyType{};

concept_map std::MoveAssignable<std::unique_future<MyType>>
{
    std::unique_future<MyType>& operator=(
        std::unique_future<MyType>&& rhs)
    {
        this->˜std::unique_future<MyType>();
        new (this) std::unique_future<MyType>(std::move(rhs));
        return *this;
    }
}

Such a concept map would allow you to use move-assignment seamlessly in constrained templates such as std::vector<>, but only for instantiations involving a user-defined type.

Given that you can write such code, it seems most unfortunate that you cannot just write a direct move-assignment in unconstrained code:

    target=std::move(source);

For the reasons presented above, UK comment 336 proposes that a move-assignment operator is added to std::unique_future<>.

Default construction of std::unique_future<>

Even with a move-assignment operator, std::unique_future<> is still severely limited, since it lacks a default constructor so you must construct it with a value. This prevents calling resize on a std::vector<std::unique_future<>>, and again limits the use of std::unique_future<> for holding the results of sub-tasks — it can be beneficial to be able to allocate the container to hold the results prior to actually starting the tasks and obtaining the correct futures. Preventing default construction makes this unnecessarily difficult. It also means that arrays can only be created if every element is initialized, which is not always readily possible.

For example, if your algorithm can be divided into a number of predefined steps, it may make sense to create an array of futures to hold the results of the subtasks in order to avoid the overhead of additional dynamic memory allocation. This is made considerably easier if the futures support default construction, since the already-constructed futures can be waited-for if subsequent tasks cannot be started for some reason, rather than just being destroyed. For example:

class task_data{};
class result_type{};

unsigned const num_steps=42;
std::unique_future<result_type> run_subtask(task_data& state,unsigned step);

void parallel_task()
{
    task_data state;
    std::unique_future<result_type> results[num_steps];
    unsigned count=0;
    try
    {
        for(count=0;count<num_steps;++count)
        {
            results[count]=run_subtask(state,count);
        }
    }
    catch(...)
    {
        state.set_cancel_flag();
        for(unsigned i=count;i!=0;)
        {
            --i;
            results[i].wait();
        }
        throw;
    }
}

Such a construction becomes more difficult if std::unique_future<> doesn't support default construction.

At first glance, omitting default construction prevents the construction of std::unique_future<> values without an associated state. However, this is not the case: such an instance can be obtained by using an object as the source of a move-construction:

void foo()
{
    std::unique_future<int> f1(make_future());
    std::unique_future<int> f2(std::move(f1));
    // f1 is now "empty", just like a default-constructed instance would be
}

Therefore UK comment 336 also proposes to allow default construction of std::unique_future<>.

Move-assignment for std::shared_future<>

std::shared_future<> is currently CopyConstructible, but not CopyAssignable or MoveAssignable. As for std::unique_future<>, this can lead to bizarre restrictions on the use of the type with containers such as std::vector<>.

The key benefit to be obtained from the lack of assignment is that instances are immutable. However, declaring individual instances const provides this property in a way much more consistent with the rest of the language.

As for std::unique_future<>, it therefore makes sense to make std::shared_future<> MoveAssignable too.

Proposed Wording

These wording changes are based on the current working paper, N2857. Additions and deletions are marked in green and red as shown here.

Changes to 30.6.4 [futures.unique_future]

Update the class synopsis of std::unique_future as follows:

template<class R>
class unique_future {
public:
    unique_future();
    unique_future(const unique_future& rhs) = delete;
    unique_future(unique_future&& rhs);
    ˜unique_future();
    unique_future & operator=(const unique_future& rhs) = delete;
    unique_future& operator=(unique_future&& rhs);

    bool waitable() const;
    // retrieving the value
    see below get() const;

    // functions to check state and wait for ready
    bool is_ready() const;
    bool has_exception() const;
    bool has_value() const;

    void wait() const;
    template <class Rep, class Period>
    bool wait_for(const chrono::duration<Rep, Period>& rel_time) const;
    template <class Clock, class Duration>
    bool wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
};

Add the following after current paragraph 1:

unique_future();

Effects:

Construct a new instance of unique_future with no associated state.

Postcondition:

waitable() returns false

Modify the current paragraph 3 (postcondition of move-constructor) as follows:

Postcondition:

rhs can be safely destroyed. Calling waitable on the newly-constructed object returns the same value as rhs.waitable() prior to the constructor invocation. rhs.waitable() returns false.

Add the following after the current paragraph 4:

unique_future& operator=(unique_future&& rhs);

Effects:

Transfer the state associated with rhs to this. If this->waitable() was true prior to the assignment, and there are no promise or packaged_task instances referencing that state, then destroy that state.

Postcondition:

Calling waitable on the newly-constructed object returns the same value as rhs.waitable() prior to the assignment invocation. rhs.waitable() returns false.

bool waitable() const;

Returns:

true if this has associated state, false otherwise.

Add a new paragraph following the current paragraph 5 as part of the description of unique_future::get():

Precondition:

waitable() returns true.

Add a new paragraph prior to the current paragraph 13 as part of the description of unique_future::wait():

Precondition:

waitable() returns true.

Add a new paragraph prior to the current paragraph 16 as part of the description of unique_future::wait_for():

Precondition:

waitable() returns true.

Add a new paragraph prior to the current paragraph 19 as part of the description of unique_future::wait_until():

Precondition:

waitable() returns true.

Changes to 30.6.5 [futures.shared_future]

Alter the class synopsis of std::shared_future as follows:

template<class R>
class shared_future {
public:
    shared_future();
    shared_future(const shared_future& rhs);
    shared_future(shared_future&& rhs);
    shared_future(unique_future<R>);
    ˜shared_future();
    shared_future & operator=(const shared_future& rhs) = delete;
    shared_future& operator=(shared_future&& rhs);

    bool waitable() const;
    // retrieving the value
    see below get() const;
    // functions to check state and wait for ready
    bool is_ready() const;
    bool has_exception() const;
    bool has_value() const;
    void wait() const;
    template <class Rep, class Period>
    bool wait_for(const chrono::duration<Rep, Period>& rel_time) const;
    template <class Clock, class Duration>
    bool wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;
};

Add the following after current paragraph 1:

shared_future();

Effects:

Construct a new instance of shared_future with no associated state.

Postcondition:

waitable() returns false

Added the following after the current paragraph 2 (effects of copy-constructor) as follows:

Postcondition:

Calling waitable on the newly-constructed object returns the same value as rhs.waitable().

shared_future(shared_future&& rhs);

Effects:

Transfer the state associated with rhs to this.

Postcondition:

Calling waitable on the newly-constructed object returns the same value as rhs.waitable() prior to the constructor invocation. rhs.waitable() returns false.

shared_future& operator=(const shared_future& rhs);

Effects:

Update this to reference the state associated with rhs. If this->waitable() was true prior to the assignment, and there are no promise, packaged_task or other shared_future instances referencing that state, then destroy that state.

Postcondition:

Calling waitable on the newly-constructed object returns the same value as rhs.waitable() prior to the assignment invocation. this and rhs reference the same associated state.

shared_future& operator=(shared_future&& rhs);

Effects:

Transfer the state associated with rhs to this. If this->waitable() was true prior to the assignment, and there are no promise, packaged_task or other shared_future instances referencing that state, then destroy that state.

Postcondition:

Calling waitable on the newly-constructed object returns the same value as rhs.waitable() prior to the assignment invocation. rhs.waitable() returns false.

bool waitable() const;

Returns:

true if this has associated state, false otherwise.

Add a new paragraph following the current paragraph 7 as part of the description of shared_future::get():

Precondition:

waitable() returns true.

Add a new paragraph prior to the current paragraph 13 as part of the description of shared_future::wait():

Precondition:

waitable() returns true.

Add a new paragraph prior to the current paragraph 16 as part of the description of shared_future::wait_for():

Precondition:

waitable() returns true.

Add a new paragraph prior to the current paragraph 19 as part of the description of shared_future::wait_until():

Precondition:

waitable() returns true.

Acknowledgements

I am grateful to Alisdair Meredith and Jonathan Wakely for their comments on drafts of this paper.