This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
shared_future
intended to work with arrays or function types?Section: 32.10.7 [futures.unique.future], 32.10.8 [futures.shared.future] Status: Resolved Submitter: Tomasz Kamiński Opened: 2020-06-28 Last modified: 2020-11-09
Priority: 0
View all other issues in [futures.unique.future].
View all issues with Resolved status.
Discussion:
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.]
[2020-07-17; Reflector prioritization]
Set priority to 0 and status to Tentatively Ready after six votes in favour during reflector discussions.
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.
Modify 32.10.7 [futures.unique.future] as indicated:
namespace std { template<class R> class future { […] }; }-?- If
-4- The implementation provides the templateis_array_v<R>
istrue
oris_function_v<R>
istrue
, the program is ill-formed.future
and two specializations,future<R&>
andfuture<void>
. These differ only in the return type and return value of the member functionget
, as set out in its description, below.Modify 32.10.8 [futures.shared.future] as indicated:
namespace std { template<class R> class shared_future { […] }; }-?- If
-4- The implementation provides the templateis_array_v<R>
istrue
oris_function_v<R>
istrue
, the program is ill-formed.shared_future
and two specializations,shared_future<R&>
andshared_future<void>
. These differ only in the return type and return value of the member functionget
, as set out in its description, below.
[2020-08-02; Daniel comments]
I'm request to reopen the issue and to follow the recent wording update of LWG 3466(i) instead.
[2020-11-09 Resolved by acceptance of 3466(i). Status changed: Tentatively Resolved → Resolved.]
Proposed resolution: