1226. Incomplete changes of #890

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 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_code and error_condition constexpr, nor does the expression *future_category satisfy 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 those make_* 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:

constexpr error_code make_error_code(future_errc e);
constexpr error_condition make_error_condition(future_errc e);

[1] Let me add that we have a related NAD issue here: 832 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:

1. Change in 32.10.1 [futures.overview], header <future> synopsis:

   extern const error_category&* const future_category();
   

2. In 32.10.1 [futures.overview]/1, Header <future> synopsis change as indicated:

   constexpr error_code make_error_code(future_errc e);
   constexpr error_condition make_error_condition(future_errc e);
   

3. Change in 32.10.3 [futures.errors]:

   extern const error_category&* const future_category();
   

   1- future_category shall point to a statically initialized object of a type derived from class error_category.

   1- Returns: A reference to an object of a type derived from class error_category.

   constexpr error_code make_error_code(future_errc e);
   

   3 Returns: error_code(static_cast<int>(e), *future_category()).

   constexpr error_codecondition make_error_condition(future_errc e);
   

   4 Returns: error_condition(static_cast<int>(e), *future_category()).