Title
future_errc enums start with value 0 (invalid value for broken_promise)
Status
c++14
Section
[futures.overview]
Submitter
Nicolai Josuttis

Created on 2011-05-18.00:00:00 last changed 122 months ago

Messages

Date: 2012-11-03.04:16:46

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:

The enum values of future_errc are distinct and not zero.
Date: 2012-11-03.04:16:46

[ 2012, Portland: applied to WP ]

Date: 2012-02-12.18:36:43

[ 2012, Kona ]

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

Date: 2011-08-17.17:30:47

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
History
Date User Action Args
2014-02-20 13:20:35adminsetstatus: wp -> c++14
2012-11-03 04:16:46adminsetmessages: + msg6262
2012-10-25 12:46:45adminsetstatus: voting -> wp
2012-10-16 15:35:12adminsetstatus: ready -> voting
2012-02-12 18:36:43adminsetmessages: + msg5998
2012-02-12 18:36:43adminsetstatus: review -> ready
2011-08-17 17:30:47adminsetstatus: new -> review
2011-05-19 20:40:37adminsetmessages: + msg5779
2011-05-18 00:00:00admincreate