Proposed resolution:

This wording is relative to the FDIS.

In [futures.overview], header <future> synopsis, fix the declaration of future_errc as follows:

namespace std {
  enum class future_errc {
    broken_promise = implementation defined,
    future_already_retrieved = implementation defined,
    promise_already_satisfied = implementation defined,
    no_state = implementation defined
  };
  […]
}

In [futures.overview], header <future> synopsis, add a paragraph after paragraph 2 as follows:

[ 2012, Portland: applied to WP ]

[ 2012, Kona ]

Moved to Tentatively Ready by the post-Kona issues processing subgroup.

In [futures.overview] enum class future_errc is defined as follows:

enum class future_errc {
  broken_promise,
  future_already_retrieved,
  promise_already_satisfied,
  no_state
};

With this declaration broken_promise has value 0, which means that for a future_error f with this code

f.code().operator bool()

yields false, which makes no sense. 0 has to be reserved for "no error". So, the enums defined here have to start with 1.

Howard, Anthony, and Jonathan have no objections.

[Discussion in Bloomington 2011-08-16]

Previous resolution:

This wording is relative to the FDIS.

1. In [futures.overview], header <future> synopsis, fix the declaration of future_errc as follows:

   namespace std {
     enum class future_errc {
       broken_promise,
       future_already_retrieved = 1,
       promise_already_satisfied,
       no_state,
       broken_promise
     };
     […]
   }
   

Is this resolution overspecified? These seem to be all implementation-defined. How do users add new values and not conflict with established error codes?

PJP proxy says: over-specified. boo.

Other error codes: look for is_error_code_enum specializations. Only one exists io_errc

Peter: I don't see any other parts of the standard that specify error codes where we have to do something similar.

Suggest that for every place where we add an error code, the following:

1. no zero values
2. all implementation defined values, so future_already_retrieved = implementation_defined
3. values are distinct