Standardization

N4570: June 2016 WG21 Meeting -- Ville Voutilainen

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

Date: 2016-01-18

June 2016 WG21 Meeting

by Ville Voutilainen

Excerpt:

The June 2016 WG21 meeting is sponsored by Symbio. The meeting will take place at the Radisson Blu Hotel, in Oulu, Finland, Monday Jun 20, 2016, to Saturday, Jun 25, 2016.

C++ Language Support for Pattern Matching and Variants -- David Sankel

A discussion on the possibility for C++ language support for pattern matching and variants.

C++ Language Support for Pattern Matching and Variants

by David Sankel

From the article:

The C++ Programming Language needs a language based variant, or at least P0095R0 argued for it at the 2015 Kona C++ standardization meeting. P0095R0, however, didn’t fully explore generalized pattern matching, which is another desirable feature that is highly related. This post explores some ways to generalize the minimal pattern matching described in P0095R0.

P0143R0: Wording for Modules -- Gabriel Dos Reis

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

Date: 2015-11-30

Wording for Modules

by Gabriel Dos Reis

Excerpt:

This documents provides formal wording for a module system for C++. This document is to be read in conjunction with document P0142R0 “A Module System for C++”. The proposed wording are with respect to WG21 Committee Draft (N4567)

2015-11 post-Kona mailing available

The 2015-11 mailing of new standards papers is now available.

NOTE: A number of these papers have already been publicized on this blog. This is the complete list including ones not previously publicized.

 

WG21 Number Title Author Document Date Mailing Date Previous Version Subgroup Disposition
SD-1 2015 PL22.16/WG21 document list John Spicer 2015-11-16 2015-11      
2015-11 post-Kona
N4553 Working Draft, C++ extensions for Concepts Andrew Sutton 2015-10-02 2015-11 N4549 Concepts  
N4554 Editor's report for the Concepts TS Andrew Sutton 2015-10-02 2015-11   Concepts  
N4555 February 2016 WG21 Meeting Barry Hedquist 2015-10-09 2015-11      
N4556 WG21 telecon minutes Marhsall Clow 2015-10-09 2015-11      
N4557 WG21 2015-07-20 Telecon (revised) Roger Orr 2015-10-24 2015-11      
N4558 Kona WG21 Minutes Jonathan Wakely 2015-11-16 2015-11      
N4559 Kona PL22.16 Minutes Jonathan Wakely 2015-11-16 2015-11      
N4560 Working Draft, C++ Extensions for Ranges Eric Niebler, Casey Carter 2015-11-06 2015-11      
N4561 Ranges Editor's Report Eric Niebler 2015-11-05 2015-11      
N4562 Working Draft, C++ Extensions for Library Fundamentals, Version 2 Geoffrey Romer 2015-11-05 2015-11 N4529    
N4563 Editor's Report for the Library Fundamentals TS Geoffrey Romer 2015-11-05 2015-11      
N4564 C++ Extensions for Library Fundamentals, Version 2 PDTS Geoffrey Romer 2015-11-05 2015-11      
N4565 Record of Response: National Body Comments ISO/IEC PDTS 19571 Technical Specification: C++ Extensions for Concurrency Barry Hedquist 2015-11-06 2015-11      
N4566 Editor's Report -- Working Draft, Standard for Programming Language C++ Richard Smith 2015-11-09 2015-11      
N4567 Working Draft, Standard for Programming Language C++ Note: Richard Smith 2015-11-09 2015-11 N4527    
P0001R1 Removing Deprecated Register Keyword Alisdair Meredith 2015-10-21 2015-11 P0001R0 Core Adopted 2015-10
P0002R1 Removing Deprecated Operator++ for bool Alisdair Meredith 2015-10-23 2015-11 P0002R0 Core Adopted 2015-10
P0004R1 Removing Deprecated Aliases in iostreams Alisdair Meredith 2015-10-19 2015-11 P0004R0 Library Evolution  
P0005R1 Adopt not_fn from Library Fundamentals 2 for C++17 Alisdair Meredith, Stephan T. Lavavej, Tomasz Kamiński 2015-10-18 2015-11 P0005R0 Library Revised P0005R2
P0005R2 Adopt not_fn from Library Fundamentals 2 for C++17 Alisdair Meredith, Stephan T. Lavavej, Tomasz Kamiński 2015-10-23 2015-11 P0005R1 Library  
P0007R1 Constant View: A proposal for a std::as_const helper function template ADAM David Alan Martin, Alisdair Meredith 2015-10-22 2015-11 P0007R0 Library Evolution  
P0012R1 Make exception specifications be part of the type system, version 5 Jens Maurer 2015-10-22 2015-11 P0012R0   Adopted 2015-10
P0013R1 Logical Operator Type Traits (revison 1) Jonathan Wakely 2015-10-23 2015-11 P0013R0 Library Evolution Adopted 2015-10
P0014R1 Proposal to add the multiline option to std::regex for its ECMAScript engine Nozomu Katō 2015-10-30 2015-11 P0014R0 Library Evolution  
P0017R1 Extension to aggregate initialization Oleg Smolsky 2015-10-24 2015-11 P0017R0 Evolution  
P0018R1 Lambda Capture of *this by Value H. Carter Edwards, Christian Trott, Hal Finkel, Jim Reus, Robin Maffeo, Ben Sander 2015-10-23 2015-11 P0018R0 Evolution  
P0022R1 Proxy Iterators for the Ranges Extensions Eric Niebler 2015-11-06 2015-11 P0022R0 Library  
P0025R1 An algorithm to "clamp" a value between a pair of boundary values Martin Moene, Niels Dekker 2015-10-29 2015-11 P0025R0 Library  
P0030R1 Proposal to Introduce a 3-Argument Overload to std::hypot Benson Ma 2015-11-06 2015-11 P0030R0 Library  
P0032R1 Homogeneous interface for variant, any and optional (Revision 1) Vicente J. Botet Escriba 2015-11-05 2015-11 P0032R0 Library Evolution  
P0051R1 C++ generic overload function (Revision 1) Vicente J. Botet Escriba 2015-11-05 2015-11 P0051R0 Library Evolution  
P0057R1 Wording for Coroutines Gor Nishanov 2015-11-06 2015-11 P0057R0 Core, Library Evolution  
P0061R1 __has_include for C++17 Clark Nelson 2015-10-23 2015-11 P0061R0   Adopted 2015-10
P0083R1 Splicing Maps and Sets (Revision 3) Alan Talbot, Jonathan Wakely, Howard Hinnant, James Dennett 2015-11-07 2015-11 P0083R0 Library Evolution  
P0092R1 Polishing Howard Hinnant 2015-10-20 2015-11 P0092R0 Library Evolution  
P0100R1 Comparison in C++ Lawrence Crowl 2015-11-07 2015-11 P0100R0 Library Evolution  
P0112R1 Networking Library (Revision 7) Christopher Kohlhoff 2015-10-23 2015-11 P0112R0 Library Evolution Adopted 2015-10
P0136R1 Rewording inheriting constructors (core issue 1941 et al) Richard Smith 2015-10-19 2015-11 P0136R0 Core Adopted 2015-10
P0144R0 Structured Bindings Herb Sutter 2015-10-14 2015-11   Evolution  
P0145R0 Expression Order of Evaluation Gabriel Dos Reis, Herb Sutter, Jonathan Caves 2015-10-01 2015-11   Evolution  
P0147R0 The Use and Implementation of Contracts Lawrence Crowl 2015-11-08 2015-11   Evolution  
P0148R0 memory_resource_ptr: A Limited Smart Pointer for memory_resource Correctness Pablo Halpern, Dietmar Kühl 2015-10-14 2015-11   Library Evolution  
P0151R0 Proposal of Multi-Declarators Andrew Tomazos 2015-10-16 2015-11   Evolution  
P0152R0 constexpr atomic::is_always_lock_free Olivier Giroux, JF Bastien, Jeff Snyder 2015-10-21 2015-11 N4509 Concurrency  
P0153R0 std::atomic_object_fence(mo, T&&...) Olivier Giroux, JF Bastien 2015-11-05 2015-11 N4522    
P0154R0 constexpr std::thread::hardware_{true,false}_sharing_size JF Bastien, Olivier Giroux 2015-10-24 2015-11 N4523    
P0155R0 Task Block R5 Pablo Halpern, Arch Robison, Hong Hong, Artur Laksberg, Gor Nishanov, Herb Sutter 2015-10-22 2015-11 N4411 Library Adopted 2015-10
P0156R0 Variadic lock_guard (Rev. 3) Mike Spertus 2015-10-21 2015-11 N4498 Evolution  
P0157R0 Handling Disappointment in C++ Lawrence Crowl 2015-11-07 2015-11   Evolution  
P0158R0 Couroutines belong in a TS Jamie Allsop, Jonathan Wakely, Christopher Kohlhoff, Anthony Williams, Roger Orr, Andy Sawyer, Jonathan Coe, Arash Partow 2015-11-06 2015-11   Evolution  
P0159R0 Draft of Technical Specification for C++ Extensions for Concurrency Artur Laksberg 2015-10-22 2015-11     Adopted 2015-10
P0160R0 Wording for removing defaults for unary folds Jens Maurer 2015-10-23 2015-11   Core  
P0162R0 A response to "P0055R0: On Interactions Between Coroutines and Networking Library" Christopher Kohlhoff 2015-11-06 2015-11      
P0163R0 shared_ptr::weak_type Arthur O'Dwyer 2015-10-23 2015-11   Library Evolution  
P0164R0 Core Language Working Group "ready" Issues William M. Miller 2015-10-23 2015-11   Core Adopted 2015-10
P0165R0 C++ Standard Library Issues to be moved in Kona Marshall Clow 2015-10-23 2015-11   Library Adopted 2015-10
P0166R0 Three interesting questions about contracts J. Daniel Garcia 2015-11-06 2015-11   Evolution  
P0167R0 Core Language Working Group "ready" Issues after the October, 2015 (Kona) meeting William M. Miller 2015-11-10 2015-11   Core  
P0169R0 regex and Unicode character types Nozomu Katō 2015-11-03 2015-11   Library evolution  
P0170R0 Wording for Constexpr Lambda Faisal Vali 2015-11-01 2015-11 N4487 Evolution  
P0171R0 Response To: Resumable Expressions P0114R0 Gor Nishanov 2015-11-06 2015-11   Evolution  
P0172R0 Abominable Function Types Alisdair Meredith 2015-11-10 2015-11   Library Evolution  

 

Trip Report: C++ Standards Meeting in Kona, October 2015--Botond Ballo

Another trip report of the last meeting in Kona:

Trip Report: C++ Standards Meeting in Kona, October 2015

by Botond Ballo

From the article:

Last week I attended a meeting of the ISO C++ Standards Committee in Kona, Hawaii. This was the second committee meeting in 2015; you can find my reports on the past few meetings here (June 2014, Rapperswil), here (November 2014, Urbana-Champaign), and here (May 2015, Lenexa). These reports, particularly the Lenexa one, provide useful context for this post.

The focus of this meeting was primarily C++17. There are many ambitious features underway for standardization, and the time has come to start deciding what which of them will make C++17 and which of them won’t. The ones that won’t will target a future standard, or a Technical Specification (which can eventually also be merged into a future standard). In addition, there are a number of existing Technical Specifications in various stages of completion...

The Variant Saga: A happy ending?

Variant is like a union, only it tells you what it currently contains, and it will barf if you try to get something out of it that is does not currently contain. It's the type safe sibling of the union:

variant<double, string> v = 42.;
double d = get<double>(v);

I had proposed a variant many moons ago (N4218). After many discussions it seemed that the committee cannot agree on what the ideal C++ variant would look like. I will resolve this cliffhanger -- but before doing that let me introduce you to some of the key discussion points.

An ideal variant will always contain one of its alternative types. But look at this code snippet:

variant<string, MyClass> v = "ABC";
v = MyClass();

The second line will destroy the old value contained in the variant and construct the new value of a different type. Now suppose that the MyClass construction threw: what will the variant contain? What happens when you call get<1>(v)? What happens when the variant gets destroyed?

We either provide the strong exception guarantee (the variant would still contain the string) -- but this requires double buffering, as for instance boost::variant does. Or we could restrict the alternative types to only those that are nothrow_move_constructible. Or we make this a new state -- "invalid, because the variant has been derailed due to an exception thrown during type changing assignment". Or we say "you shouldn't write code that behaves like this; if you do you're on your own", i.e. undefined behavior. The committee was discussing what to do, and so was The Internet. There are other design decisions -- default construction, visitation etc -- but they are all insignificant compared to how to deal with the throwing, type-changing assignment.

I have tried to present the options and their pros and cons in P0086. In short: it's incredibly difficult and fragile to predict whether a type is_nothrow_move_constructible. And double buffering -- required for a strong exception guarantee -- kills the quest for an efficient variant. But efficiency is one of the main motivations for using a discriminated union.

After the second Library Evolution Working Group (LEWG) review in Lenexa, we got P0088R0: a design that was making this invalid state extremely rare. But if it happened, access to the value would result in undefined behavior. This caused a vivid reaction from the committee members. And from The Internet. Hundreds of emails on the committee email lists. Many many smart and convincing blog posts.

In the end, different parts of the committee strongly supported different designs -- and vetoing other designs. Massive disagreement. So when we came to our C++ Standards Meeting in Kona, it was immediately clear that we needed to expose this to the full committee (and not just LEWG). The expectation was that we would declare variant dead, and keep it locked away for the next five years. At least. (An I would have time to water my fishes again.)

So back to the cliffhanger. On the full committee, Monday evening stage in Kona were David Sankel and I. We presented (and represented) the different design options. While we were discussing with the committee members, live and uncut and on stage, David and I realized that we could make it happen. "The Kona Kompromise": similar to P0088R0, but instead of undefined behavior when extracting the value of such a zombie variant it would just throw!

The Kona Kompromise means that we don't pay any efficiency for the extremely rare case of a throwing move. The interface stays nice and clean. A variant of n alternatives is a "mostly" an n-state type. It offers the basic exception guarantee at no relevant performance loss. It is a safe vocabulary type for every-day use, also for novices. The vast majority of the committee was convinced by this idea. Almost everyone in the room was happy!

Do we have a std::variant now? Not yet. But we are a giant leap closer: variant is now under wording review with the Library Working Group (LWG); I will publish a new revision in the Kona post-mailing (P0088R1). This will get re-reviewed in Jacksonville, first week of March. Once LWG gives the green light, the full committee can vote variant into a Technical Specification (TS) as std::experimental::variant. Now that a large fraction of the committee has expressed its consent (happiness, even!), I expect that this will be in the TS called Library Fundamentals, v3. It might or might not make it into C++17 -- that depends mostly on how quickly I manage to bring P0088 into an acceptable state, and how quickly we will gain use experience with variant.

So there is one thing I'd really appreciate your help with: std::experimental::variant will show up in library implementations near you, likely in their first releases next year. It would be fantastic if you could try it out, and as importantly: give feedback, on the public forums or by contacting me directly ([email protected]). Your feedback will tell us whether the design decisions we took are the right ones, for instance regarding default construction, visitation, performance, and especially converting construction and assignment. As they say here: Mahalo!

Axel Naumann, CERN ([email protected])