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-09

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.