Standardization

N4164: Forwarding References -- Herb Sutter, Bjarne Stroustrup, Gabriel Dos Reis

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4164

Date: 2014-10-06

Forwarding References

by Herb Sutter, Bjarne Stroustrup, Gabriel Dos Reis

Excerpt:

To the C++ programmer, a parameter of type C&& is always an rvalue reference -- except when C is a template parameter type or auto, in which case it behaves very differently even though language-technically it is still an rvalue reference.

We intentionally overloaded the && syntax with this special case, but we did not give this special case a name. It needs a distinct name so that we can talk about it and teach it. This has already been discovered in the community, thanks to Scott Meyers in particular. [1]

In the absence of our giving this construct a distinct name, the community has been trying to make one. The one that is becoming popular is “universal reference.” [1] Unfortunately, as discussed in §3.1 below, this is not an ideal name, and we need to give better guidance to a suitable name.

The name that has the most support in informal discussions among committee members, including the authors, is “forwarding reference.” Interestingly, Meyers himself initially introduced the term “forwarding reference” in his original “Universal References” talk, [2] but decided to go with “universal references” because at the time he did not think that “forwarding references” reflected the fact that auto&& was also included; however, in §3.3 below we argue why auto&& is also a forwarding case and so is rightly included.

N4166: Movable initializer lists -- David Krauss

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4166

Date: 2014-10-06

Movable initializer lists

by David Krauss

Excerpt:

Often std::initializer_list cannot be used, or it requires a const_cast hack, as it provides read-only access to its sequence. This is a consequence of the sequence potentially being shared with other initializer_list objects, although often it is statically known to be uniquely local. A new initializer list class template is proposed to allow function parameters which may leverage (by overloading) or require strict ownership. Addition of this class does not impinge on the cases where the sequence should be shared. No breaking changes are proposed.

N4157: Relaxing Packaging Rules for Exceptions Thrown by Parallel Algorithms -- Arch Robison

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4157

Date: 2014-10-02

Relaxing Packaging Rules for Exceptions Thrown by Parallel Algorithms

by Arch Robison

Excerpt:

If an algorithm invocation throws only a single exception, then it should be allowed to propagate the singleton exception directly instead of returning it wrapped in an exception_list.

N4154: Operator assert -- David Krauss

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4154

Date: 2014-09-30

Operator assert

by David Krauss

Excerpt:

The assert macro has never behaved much like a real function, and for the foreseeable future, it will look and smell like an operator. The way the macro is specified by C precludes it from providing optimization hints in production mode, but allows it to execute arbitrary side effects in debug mode. Adding assert as a keyword and built-in operator would have benefits but essentially no downside.

This will resolve LWG DR 2234 and 2413.

N4152: uncaught_exceptions -- Herb Sutter

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4152

Date: 2014-09-30

uncaught_exceptions

by Herb Sutter

Excerpt:

This paper is a revision of N3614 to implement EWG direction in Bristol.

...

This paper proposes a new function int std::uncaught_exceptions() that returns the number of exceptions currently active, meaning thrown or rethrown but not yet handled.

N4149: Categorically qualified classes -- David Krauss

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4149

Date: 2014-09-25

Categorically qualified classes

by David Krauss

Excerpt:

Some classes only work in certain contexts: scope guards are usually useless as subexpressions, and expression template placeholders malfunction as local variables. An unused function result may signal that the caller intends to follow a different protocol, such as with std::async. This proposal extends class definitions to prevent such errors, and adds a mechanism to automatically resolve them by type substitution, such as a value type for an expression template. Additionally, generation of non-movable objects becomes more tractable.

The added functionality includes that of the “auto evaluation” proposals [1]. This proposal intends to be more expressive, more broadly applicable, and easier to adopt and use.

N4148: Disallowing Inaccessible Operators From Trivially Copyable -- Matheus Izvekov

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4148

Date: 2014-09-24

Disallowing Inaccessible Operators From Trivially Copyable

by Matheus Izvekov

Excerpt:

This proposal aims to solve a serious flaw in the definition of the trivially copyable concept. Presently, classes with deleted or inaccessible copy/move constructors, copy/move assignment operators and destructor are allowed to be trivially copyable, which might seem counterintuitive.

N4147: Inline variables, or encapsulated expressions -- David Krauss

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4147

Date: 2014-09-25

Inline variables, or encapsulated expressions

by David Krauss

Excerpt:

Inline functions have favorable behavior for interfaces which cannot be exposed as objects. Often, users are encouraged to use them to wrap global variables, despite unnatural boilerplate. Other workarounds include class static data members, enumerators, macros, and variable templates, all with awkward syntax or downsides and limited applicability. This proposal defines the inline specifier on variable definitions to indicate semantics similar to inline function evaluation and linkage. More generally, this produces a facility for named values, or variables without persistence, which may supersede or complement the various workarounds.

N4146: Disposition of Comments, ISO/IEC DIS 14882, C++ 2014 -- Barry Hedquist

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4146

Date: 2014-09-23

Disposition of Comments, ISO/IEC DIS 14882, C++ 2014

by Barry Hedquist

Excerpt:

Attached is WG21 N4146, the Disposition of Comments for ISO/IEC DIS 14882, Draft Information Standard ISO/IEC 14882:2014.

Document numbers referenced in the ballot comments are WG21 documents unless otherwise stated.

N4133: Cleanup for exception-specification and throw-expression -- Jens Maurer

A new WG21 paper is available. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4133

Date: 2014-09-10

Cleanup for exception-specification and throw-expression

by Jens Maurer

Excerpt:

This paper proposes to adjust the wording for exceptions to achieve the following goals:

  • Exception specifications as a semantic concept are separated from the grammar term exception-specification
  • The description of throw-expression is integrated into clause 5.

The changes are intended to be editorial only, not changing semantics. Due to the size of the changes, it seems prudent to have a full CWG review for these instead of leaving the issue to the project editor alone.