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.

### 1513. 'launch' enum too restrictive

Section: 32.9 [futures] Status: Resolved Submitter: Switzerland Opened: 2010-08-25 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [futures].

View all issues with Resolved status.

Discussion:

Addresses CH-36

Providing only three different possible values for the enum `launch` and saying that `launch::any` means either `launch::sync` or `launch::async` is very restricting. This hinders future implementors to provide clever infrastructures that can simply by used by a call to `async(launch::any,...)`. Also there is no hook for an implementation to provide additional alternatives to `launch` enumeration and no useful means to combine those (i.e. interpret them like flags). We believe something like `async(launch::sync | launch::async, ...)` should be allowed and can become especially useful if one could say also something like `async(launch::any & ~launch::sync, ....)` respectively. This flexibility might limit the features usable in the function called through `async()`, but it will allow a path to effortless profit from improved hardware/software without complicating the programming model when just using `async(launch::any,...)`

[ Resolution proposed by ballot comment: ]

Change in 32.9.1 [futures.overview] 'enum class launch' to allow further implementation defined values and provide the following bit-operators on the launch values (`operator|`, `operator&`, `operator~` delivering a `launch` value).

Note: a possible implementation might use an unsigned value to represent the `launch` enums, but we shouldn't limit the standard to just 32 or 64 available bits in that case and also should keep the launch enums in their own enum namespace.

Change [future.async] p3 according to the changes to `enum launch`. change --`launch::any` to "the implementation may choose any of the policies it provides." Note: this can mean that an implementation may restrict the called function to take all required information by copy in case it will be called in a different address space, or even, on a different processor type. To ensure that a call is either performed like `launch::async` or `launch::sync` describe one should call `async(launch::sync|launch::async,...)`

[ 2010-11-02 Daniel comments: ]

> The new paper n3113 provides concrete wording.

Proposed resolution:

Resolved by n3188.