Standardization

N4127: Checked-dereference conditions—Eelis van der Weegen

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: N4127

Date: 2014-07-20

Checked-dereference conditions

by Eelis van der Weegen

Excerpt:

This is a proposal to add a new form of condition...

For example,  if (T x : e) s  translates to  if (auto && __p = e) { T x = *__p; s }  for some invisible name __p.

Translation for the new form of condition in a while or for loop is analogous.

The "next generation" version where the type defaults to auto && is also proposed.

Trip Report: C++ Standards Committee Meeting in Rapperswil, June 2014—Botond Ballo

Here's one participant's view of the recent standards meeting with some interesting personal perspective.

Trip Report: C++ Standards Committee Meeting in Rapperswil, June 2014

by Botond Ballo

From the article:

Last [month] I attended another meeting of the ISO C++ Standards Committee in Rapperswil, Switzerland (near Zurich). This is the third Committee meeting I have attended; you can find my reports about the previous two here (September 2013, Chicago) and here (February 2014, Issaquah). These reports, particularly the Issaquah one, provide useful context for this post.

With C++14′s final ballot being still in progress, the focus of this meeting was the various language and library Technical Specifications (TS) that are planned as follow-ups to C++14, and on C++17. ...

Post-Rapperswil mailing available

The post-Rapperswil mailing of new standards papers is now available.

Many of the papers in the mailing have already been published individually on this blog.

NOTE: The following are only those papers in the mailing that have not already been publicized on this blog.

WG21 Number Title Author Document Date Mailing Date Previous Version Subgroup Disposition
N4054 PL22.16 2014-06 Rapperswil Minutes Ville Voutilainen 2014-07-03 2014-07      
N4057 A Proposal to Add a Const-Propagating Wrapper to the Standard Library J. Coe, R. Mill 2014-07-02 2014-07 N3973 Library  
N4060 Changes to vector_execution_policy Pablo Halpern 2014-06-11 2014-07   Concurrency  
N4061 Greatest Common Divisor and Least Common Multiple, v3 Walter E. Brown 2014-06-30 2014-07 N3913 Library  
N4064 Improving pair and tuple, revision 2 Daniel Krügler 2014-07-02 2014-07 N3739 Library  
N4065 make_array, revision 2 Zhihao Yuan 2014-06-26 2014-07 N4031 Library  
N4066 Delimited iterators (Rev. 3) M. Spertus, N. Wilson 2014-06-18 2014-07 N4007 Library  
N4068 Toward More Expressive Iterator Tags Bill Seymour 2014-06-28 2014-07   Library  
N4069 C++ Ostream Buffers L. Crowl, P. Sommerlad 2014-06-18 2014-07 N3978 Concurrency  
N4072 Fixed Size Parameter Packs Maurice Bos 2014-05-26 2014-07   Evolution  
N4075 Centralized Defensive-Programming Support for Narrow Contracts (Revision 5) J. Lakos, A. Zakharov, A. Beels 2014-06-20 2014-07 N3997 Library  
N4081 Working Draft, C++ Extensions for Library Fundamentals Jeffrey Yasskin 2014-07-07 2014-07 N4023    
N4082 Programming Languages — C++ Extensions for Library Fundamentals Jeffrey Yasskin 2014-07-07 2014-07      
N4083 Editor's Report for Version 1 of the Library Fundamentals TS Jeffrey Yasskin 2014-07-07 2014-07      
N4084 Working Draft, C++ Extensions for Library Fundamentals, Version 2 Jeffrey Yasskin 2014-07-06 2014-07      
N4085 Editor's Report for Version 2 of the Library Fundamentals TS Jeffrey Yasskin 2014-07-06 2014-07      
N4086 Removing trigraphs??! Richard Smith 2014-06-18 2014-07 N3981 Evolution  
N4088 Task Region R3 P. Halpern, A. Robison, A. Laksberg, H. Sutter, et al. 2014-06-21 2014-07 N3991 Library  
N4089 Safe conversions in unique_ptr<T[]>, revision 2 Geoffrey Romer 20140625 2014-07 N4042 Library  
N4090 The Maladies of All Member Templates: An Incomplete Biography of Specialization (DR727 + DR1755) Faisal Vali 2014-06-21 2014-07 N4042 Library  
N4091 C++ Standard Core Language Active Issues, Revision 90 William M. Miller 2014-07-07 2014-07 N4018 Core  
N4092 C++ Standard Core Language Defect Reports and Accepted Issues, Revision 90 William M. Miller 2014-07-07 2014-07 N4019 Core  
N4093 C++ Standard Core Language Closed Issues, Revision 90 William M. Miller 2014-07-07 2014-07 N4020 Core  
N4094 Response To: Let return {expr} Be Explicit H. Hinnant, V. Voutilainen 2014-07-06 2014-07   Evolution  
N4104 Working Draft, Technical Specification for C++ Extensions for Parallelism Jared Hoberock 2014-07-04 2014-07 N3960    
N4105 Information technology – Programming languages, their environments and system software interfaces – Technical Specification for C++ Extensions for Parallelism Jared Hoberock 2014-07-04 2014-07      
N4106 Parallelism TS Editor's Report, post-Rapperswil Jared Hoberock 2014-07-04 2014-07      
N4107 Working Draft, Technical Specification for C++ Extensions for Concurrency Artur Laksberg 2014-07-07 2014-07 N3970    
N4108 Concurrency TS Editor's Report, July 2014 Artur Laksberg 2014-07-02 2014-07      
N4111 Static reflection (rev. 2) Matúš Chochlík 2014-07-02 2014-07   Reflection  
N4115 Searching for Types in Parameter Packs B. Seymour, S. Lavavej 2014-07-04 2014-07   Library  
N4117 C++ Standard Library Active Issues List (Revision R89) Alisdair Meredith 2014-07-08 2014-07 N3967 Library  
N4118 C++ Standard Library Defect Report List (Revision R89) Alisdair Meredith 2014-07-08 2014-07 N3968 Library  
N4119 C++ Standard Library Closed Issues List (Revision R89) Alisdair Meredith 2014-07-08 2014-07 N3969 Library  
N4120 Null Coalescing Conditional Operator Alexander Bock 2014-07-02 2014-07   Evolution  

 

N4109: A proposal to add a utility class to represent expected monad—R1—V Escriba, P Talbot

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: N4109

Date: 2014-06-29

A proposal to add a utility class to represent expected monad -- Revision 1

by Vicente J. Botet Escriba and Pierre Talbot

Excerpt:

1 History

R1- Revision of N4015 [9] after Rapperswil feedback:

  • Switch the expected class template parameter order from expected<E,T> to expected<T,E>.
  • Make the unexpected value a salient attribute of the expected class concerning the relational operators.
  • Removed open point about making expected<T,E> and expected<T> different classes.

2 Introduction

Class template expected<T,E> proposed here is a type that may contain a value of type T or a value of type E in its storage space. T represents the expected value, E represents the reason explaining why it doesn’t contains a value of type T, that is the unexpected value. Its interface allows to query if the underlying value is either the expected value (of type T) or an unexpected value (of type E). The original idea comes from Andrei Alexandrescu C++ and Beyond 2012: Systematic Error Handling in C++ talk [2]. The interface and the rational are based on std::optional N3793 [5] and Haskell monads. We can consider that expected<T,E> is a generalization of optional<T> providing in addition a monad interface and some specific functions associated to the unexpected type E. It requires no changes to core language, and breaks no existing code.

N4110: Exploring the design space of contract specifications for C++—J. Daniel Garcia

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: N4110

Date: 2014-07-06

Exploring the design space of contract specifications for C++

by J. Daniel Garcia

Excerpt:

This paper explores the design space for introducing contracts as part of the interface of functions and types. The goal is to address the problem of specifying an interface (with special attention to standard library interfaces) making a clear distinction between a contract violation and an explicitly thrown exception. Preconditions and postconditions are attached to function declarations (i.e. to interfaces) rather than to de nitions, and are, in principle, checked before and after a function's de nition is entered. No macros are needed.

N4121: Compile-Time String: std::string_literal<n>—Andrew Tomazos

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: N4121

Date: 2014-07-04

Compile-Time String: std::string_literal<n>

by Andrew Tomazos

Excerpt:

We propose the addition of a class template std::string_literal<n> to the LFTS (and eventually merged into the Strings Standard Library) for the purposes of working with text at compiletime.

The proposed template is a pure library helper class and does not require core language changes or compiler support.

This proposal is depended upon and is blocking N3815 > N4027 > N4113 (Reflection Type Traits) from SG7, which needs to produce compiletime text for reflection of entity names.

N4095-97: File System TS Issues Lists—Beman Dawes

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document numbers: N4095-97

Date: 2014-07-05

File System TS Active Issues List (Revision R2)

File System TS Closed Issues List (Revision R2)

File System TS Defect Report List (Revision R2)

by Beman Dawes

4098-99: File System TS Working Draft and Editor’s Report—Beman Dawes

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

Document number: N4098-99

Date: 2014-07-05

File System TS Editor's Report, Post-Rapperswil

Working Draft, Technical Specification — File System

by Beman Dawes

Excerpt:

N4099 is the latest File System TS Working Draft. It contains the changes to the File System TS working paper as directed by the committee at the Rapperswil meeting. It also contains editorial changes not requiring committee approval. Details of the changes are listed below.

N4074: Let return{expr} Be Explicit, Revision 2—Herb Sutter

A new WG21 paper is available. A copy is linked below, and the paper will also appear in the next normal WG21 mailing. If you are not a committee member, please use the comments section below or the std-proposals forum for public discussion.

Document number: N4074

Date: 2014-07-02

Let return{expr} Be Explicit, Revision 2

by Herb Sutter

Excerpt:

This paper is a followup to N4029 to follow EWG preference for a variation on that proposal, namely allowing explicit constructors to be called by the syntax return {expr};, with the same semantics as initializing a local variable using return_type var{expr};. This addresses EWG issue #114.

Thanks to Richard Smith for his assistance with the proposed wording. Thanks to Peter Dimov, Gabriel Dos Reis, Howard Hinnant, Stephan T. Lavavej, Mike Miller, Bjarne Stroustrup, Ville Voutilainen, Jona-than Wakely and all others who provided comments on this topic and/or drafts of this paper.