future_errc
enums start with value 0 (invalid value for broken_promise
)Section: 32.10.1 [futures.overview] Status: C++14 Submitter: Nicolai Josuttis Opened: 2011-05-18 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [futures.overview].
View all issues with C++14 status.
Discussion:
In 32.10.1 [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.
In 32.10.1 [futures.overview], header
<future>
synopsis, fix the declaration offuture_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:
[2012, Kona]
Moved to Tentatively Ready by the post-Kona issues processing subgroup.
[2012, Portland: applied to WP]
Proposed resolution:
This wording is relative to the FDIS.
In 32.10.1 [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 32.10.1 [futures.overview], header <future>
synopsis, add a paragraph after paragraph 2 as follows:
future_errc
are distinct and not zero.