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

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

Section: 32.9.6 [futures.promise] Status: WP Submitter: Tomasz Kamiński Opened: 2020-07-18 Last modified: 2020-11-15

Priority: 3

View other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with WP status.

Discussion:

The resolution of the LWG 3458 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<T> 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<T>, for which any call to get_future() would be ill-formed, if T is of array or function type.

[Note: promise<int[10]> 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 the wording below uses instead the more general "ill-formed" vocabulary.

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

    namespace std {
      template<class R>
      class promise {
        […]
      };
      […]
    }
    

    -?- If is_array_v<R> is true or is_function_v<R> 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.

[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.9.6 [futures.promise] as indicated:

    namespace std {
      template<class R>
      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<R&> and promise<void>. 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.9.7 [futures.unique.future] as indicated:

    namespace std {
      template<class R>
      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<R&> and future<void>. 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.9.8 [futures.shared.future] as indicated:

    namespace std {
      template<class R>
      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<R&> and shared_future<void>. These differ only in the return type and return value of the member function get, as set out in its description, below.