This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Section: 32.10.3 [futures.errors] Status: Resolved Submitter: Daniel Krügler Opened: 2009-10-05 Last modified: 2016-01-28
Priority: Not Prioritized
View all issues with Resolved status.
Discussion:
Defect issue 890(i) overlooked to adapt the future_category from
32.10.1 [futures.overview] and 32.10.3 [futures.errors]:
extern const error_category* const future_category;
which should be similarly transformed into function form.
[ 2009-10-27 Howard: ]
Moved to Tentatively Ready after 5 positive votes on c++std-lib.
[ 2009-11-11 Daniel adds: ]
I just observe that the proposed resolution of this issue is incomplete and needs to reworded. The problem is that the corresponding declarations
constexpr error_code make_error_code(future_errc e); constexpr error_condition make_error_condition(future_errc e);as constexpr functions are incompatible to the requirements of constexpr functions given their specified implementation. Note that the incompatibility is not a result of the modifications proposed by the issue resolution, but already existed within the N2960 state where we have
extern const error_category* const future_category;combined with
constexpr error_code make_error_code(future_errc e);3 Returns:
error_code(static_cast<int>(e), *future_category).constexpr error_code make_error_condition(future_errc e);4 Returns:
error_condition(static_cast<int>(e), *future_category).Neither is any of the constructors of
error_codeanderror_conditionconstexpr, nor does the expression*future_categorysatisfy the requirements for a constant expression (7.7 [expr.const]/2 bullet 6 in N3000).The simple solution is just to remove the constexpr qualifiers for both functions, which makes sense, because none of the remaining
make_error_*overloads in the library is constexpr. One might consider to realize that thosemake_*functions could satisfy the constexpr requirements, but this looks not like an easy task to me, because it would need to rely on a not yet existing language feature. If such a change is wanted, a new issue should be opened after the language extension approval (if at all) [1].If no-one complaints I would like to ask Howard to add the following modifications to this issue, alternatively a new issue could be opened but I don't know what the best solution is that would cause as little overhead as possible.
What-ever the route is, the following is my proposed resolution for this issue interaction part of the story:
In 32.10.1 [futures.overview]/1, Header
<future>synopsis and in 32.10.3 [futures.errors]/3+4 change as indicated:constexprerror_code make_error_code(future_errc e);constexprerror_condition make_error_condition(future_errc e);[1] Let me add that we have a related NAD issue here: 832(i) so the chances for realization are little IMO.
[ Howard: I've updated the proposed wording as Daniel suggests and set to Review. ]
[ 2009-11-13 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
[ 2010 Pittsburgh: ]
Moved to
NAD EditorialResolved. Rationale added below.
Rationale:
Solved by N3058.
Proposed resolution:
Change in 32.10.1 [futures.overview], header <future> synopsis:
externconst error_category&* constfuture_category();
In 32.10.1 [futures.overview]/1, Header <future> synopsis
change as indicated:
constexprerror_code make_error_code(future_errc e);constexprerror_condition make_error_condition(future_errc e);
Change in 32.10.3 [futures.errors]:
externconst error_category&* constfuture_category();
1-future_categoryshall point to a statically initialized object of a type derived from classerror_category.1- Returns: A reference to an object of a type derived from class
error_category.constexprerror_code make_error_code(future_errc e);3 Returns:
error_code(static_cast<int>(e),.*future_category())constexprerror_codecondition make_error_condition(future_errc e);4 Returns:
error_condition(static_cast<int>(e),.*future_category())