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 other active issues in [futures.promise].

View all other issues in [futures.promise].

View all issues with C++23 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.10.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.10.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.10.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.10.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.