Document number:  N4123
Date:             2014-10-10
Project:          Programming Language C++
Reference:        ISO/IEC IS 14882:2011(E)
Reply to:         Artur Laksberg, Microsoft Corp. arturl@microsoft.com
                  Vicente J. Botet Escriba, vicente.botet@wanadoo.fr






Improvements to the Concurrency Technical Specification

Introduction

Motivation and Goals

This document proposes improvements to N4107, the current Working Draft of the Concurrency TS.

The document is motivated by N4032 and N4048, which were presented to SG1 at the Rapperswil meeting. This document collects the parts of these papers that received positive feedback from SG1 and presents them as a combined set of proposed changes to the Concurrency TS.

In addition, the paper also addresses numerous issues discovered and reported to the authors by various individuals, namely Agustín Bergé, Hartmut Kaiser and Anthony Williams.

The authors seek feedback from SG1 on this document. If directed by SG1, all or some of the changes proposed in this document will be incorporated into the next Working Paper of the Concurrency TS.

How To Read This Document

The proposed changes are presented as "diffs" to N4107 marked as insertions and deletions.

General

Namespaces, headers, and modifications to standard classes

Some of the extensions described in this Technical Specification represent types and functions that are currently not part of the C++ Standards Library, and because these extensions are experimental, they should not be declared directly within namespace std. Instead, such extensions are declared in namespace std::experimental.

Once standardized, these components are expected to be promoted to namespace std.

Unless otherwise specified, references to such entities described in this Technical Specification are assumed to be qualified with std::experimental, and references to entities described in the C++ Standard Library are assumed to be qualified with std::.

This section reflects the consensus between the LWG and LEWG at the Chicago 2013 and Issaquah 2014 meetings.

Since the extensions described in this technical specification are experimental and not part of the C++ standard library, they should not be declared directly within namespace std. Unless otherwise specified, all components described in this technical specification either:

Each header described in this technical specification shall import the contents of std::experimental::concurrency_v1 into std::experimental as if by

namespace std {
  namespace experimental {
    inline namespace concurrency_v1 {}
  }
}

Unless otherwise specified, references to other entities described in this technical specification are assumed to be qualified with std::experimental::concurrency_v1::, and references to entities described in the standard are assumed to be qualified with std::.

Extensions that are expected to eventually be added to an existing header <meow> are provided inside the <experimental/meow> header, which shall include the standard contents of <meow> as if by

#include <meow>

New headers are also provided in the <experimental/> directory, but without such an #include.

C++ library headers
  • <experimental/future>

Future plans (Informative)

This section describes tentative plans for future versions of this technical specification and plans for moving content into future versions of the C++ Standard.

The C++ committee intends to release a new version of this technical specification approximately every year, containing the library extensions we hope to add to a near-future version of the C++ Standard. Future versions will define their contents in std::experimental::concurrency_v2, std::experimental::concurrency_v3, etc., with the most recent implemented version inlined into std::experimental.

When an extension defined in this or a future version of this technical specification represents enough existing practice, it will be moved into the next version of the C++ Standard by removing the experimental::concurrency_vN segment of its namespace and by removing the experimental/ prefix from its header's path.

Feature-testing recommendations (Informative)

For the sake of improved portability between partial implementations of various C++ standards, WG21 (the ISO technical committee for the C++ programming language) recommends that implementers and programmers follow the guidelines in this section concerning feature-test macros. WG21's SD-6 makes similar recommendations for the C++ Standard itself.

Implementers who provide a new standard feature should define a macro with the recommended name, in the same circumstances under which the feature is available (for example, taking into account relevant command-line options), to indicate the presence of support for that feature. Implementers should define that macro with the value specified in the most recent version of this technical specification that they have implemented. The recommended macro name is "__cpp_lib_experimental_" followed by the string in the "Macro Name Suffix" column.

Programmers who wish to determine whether a feature is available in an implementation should base that determination on the presence of the header (determined with __has_include(<header/name>)) and the state of the macro with the recommended name. (The absence of a tested feature may result in a program with decreased functionality, or the relevant functionality may be provided in a different way. A program that strictly depends on support for a feature can just try to use the feature unconditionally; presumably, on an implementation lacking necessary support, translation will fail.)

Significant features in this technical specification
Doc. No. Title Primary Section Macro Name Suffix Value Header
N3875 Improvements to std::future and Related APIs future_continuations 201410 code><experimental/future>

Acknowledgments

The authors are grateful to Agustín Bergé, Hartmut Kaiser and Anthony Williams for their contributions.