This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++23 status.

3466. Specify the requirements for promise/future/shared_future consistently

Section: 32.10.6 [futures.promise] Status: C++23 Submitter: Tomasz Kamiński Opened: 2020-07-18 Last modified: 2023-11-22

Priority: 3

View all other issues in [futures.promise].

View all issues with C++23 status.

Discussion:

The resolution of the LWG 3458(i) clearly specified the requirement that future/shared_future are ill-formed in situations when T is native array or function type. This requirement was not strictly necessary for future as it was already ill-formed due the signature of the get function (that would be ill-formed in such case), however it was still added for consistency of specification. Similar, requirement should be introduced for the promise, for which any call to get_future() would be ill-formed, if T is of array or function type.

[Note: promise is ill-formed for libstdc++ and libc++, see this code]

[2020-07-26; Reflector prioritization]

Set priority to 3 after reflector discussions. Tim Song made the suggestion to replace the P/R wording by the following alternative wording:

For the primary template, R shall be an object type that meets the Cpp17Destructible requirements.

Previous resolution [SUPERSEDED]:

This wording is relative to N4861.

Ideally the wording below would use a Mandates: element, but due to the still open issue LWG 3193(i) the wording below uses instead the more general "ill-formed" vocabulary.

  1. Modify 32.10.6 [futures.promise] as indicated:

    namespace std {
  template
  class promise {
    […]
  };
  […]
}

    -?- If is_array_v is true or is_function_v is true, the program is ill-formed.

[2020-08-02; Daniel comments and provides alternative wording]

Following the suggestion of Tim Song a revised wording is provided which is intended to replace the currently agreed on wording for LWG 3458(i).

[2020-08-21; Issue processing telecon: Tentatively Ready]

Discussed a note clarifying that Cpp17Destructible disallows arrays (as well as types without accessible destructors). Can be added editorially.

[2020-11-09 Approved In November virtual meeting. Status changed: Tentatively Ready → WP.]

Proposed resolution:

This wording is relative to N4861.

  1. Modify 32.10.6 [futures.promise] as indicated:

    namespace std {
  template
  class promise {
    […]
  };
  […]
}

    -?- For the primary template, R shall be an object type that meets the Cpp17Destructible requirements.

    -1- The implementation provides the template promise and two specializations, promise and promise. These differ only in the argument type of the member functions set_value and set_value_at_thread_exit, as set out in their descriptions, below.

  2. Modify 32.10.7 [futures.unique.future] as indicated:

    namespace std {
  template
  class future {
    […]
  };
}

    -?- For the primary template, R shall be an object type that meets the Cpp17Destructible requirements.

    -4- The implementation provides the template future and two specializations, future and future. These differ only in the return type and return value of the member function get, as set out in its description, below.

  3. Modify 32.10.8 [futures.shared.future] as indicated:

    namespace std {
  template
  class shared_future {
    […]
  };
}

    -?- For the primary template, R shall be an object type that meets the Cpp17Destructible requirements.

    -4- The implementation provides the template shared_future and two specializations, shared_future and shared_future. These differ only in the return type and return value of the member function get, as set out in its description, below.