Proposed resolution:

Insert the following extra paragraphs:

In [futures.atomic_future]

bool is_ready() const;

17 Precondition Requires: valid() == true.

18 Returns: true only if the associated state is ready.

Throws: future_error with an error condition of no_state if the precondition is not met.

bool has_exception() const;

Requires: valid() == true.

19 Returns: true only if the associated state is ready and contains an exception.

Throws: future_error with an error condition of no_state if the precondition is not met.

bool has_value() const;

Requires: valid() == true.

20 Returns: true only if the associated state is ready and contains a value.

Throws: future_error with an error condition of no_state if the precondition is not met.

void wait() const;

Requires: valid() == true.

22 Effects: blocks until ...

Throws: future_error with an error condition of no_state if the precondition is not met.

template <class Rep, class Period>
  bool wait_for(const chrono::duration<Rep, Period>& rel_time) const;

Requires: valid() == true.

23 Effects: blocks until ...

24 Returns: true only if ...

Throws: future_error with an error condition of no_state if the precondition is not met.

template <class Clock, class Duration>
  bool wait_until(const chrono::time_point<Clock, Duration>& abs_time) const;

Requires: valid() == true.

25 Effects: blocks until ...

26 Returns: true only if ...

Throws: future_error with an error condition of no_state if the precondition is not met.

Rationale:

Solved by N3058.

[ 2010 Pittsburgh: Moved to NAD EditorialResolved. Rationale added below. ]

[ 2010-01-23 See discussion starting with Message c++std-lib-26666. ]

The revised futures package in the current working paper simplified the is_ready/has_exception/has_value set of APIs, replacing them with a single 'valid' method. This method is used in many places to signal pre- and post- conditions, but that edit is not complete.

Atomic future retains the extended earlier API, and provides defined, synchronized behaviour for all calls. However, some preconditions and throws clauses are missing, which can easily be built around the new valid() api. Note that for consistency, I suggest is_ready/has_exception/has_value throw an exception if valid() is not true, rather than return false. I think this is implied by the existing pre-condition on is_ready.