Title
Is shared_future intended to work with arrays or function types?
Status
new
Section
[futures.unique.future][futures.shared.future]
Submitter
Tomasz Kamiński

Created on 2020-06-28.00:00:00 last changed 6 days ago

Messages

Date: 2020-06-28.15:13:05

Proposed resolution:

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 [futures.unique.future] as indicated:

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

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

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

  2. Modify [futures.shared.future] as indicated:

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

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

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

Date: 2020-06-28.00:00:00

Currently there is no prohibition of creating shared_future<T> where T is either an array type or a function type. However such objects cannot be constructed, as the corresponding future<T>, is ill-formed due the signature get() method being ill-formed — it will be declared as function returning an array or function type, respectively. [Note: For shared_future get always returns an reference, so it is well-formed for array or function types.]

History
Date User Action Args
2020-06-28 12:53:26adminsetmessages: + msg11353
2020-06-28 00:00:00admincreate