Announcing a financial assistance policy for ISO C++ meetings

Most of the following announcement will not immediately affect those who are not C++ standards committee members, but I hope everyone reading this blog who uses and relies on C++ will benefit from this new program.


I’m pleased to share that today at the ISO C++ meeting in Lenexa, Kansas, USA, the Standard C++ Foundation launched a new financial assistance policy intended to facilitate the work of WG21. You can find the policy here.

Thank you!

Before I mention details, let me thank two important groups without whose support this would not be possible:

  • Thank you to the members of the Standard C++ Foundation whose logos you see at right. Their financial investment in the Foundation has provided the core funding to support the Foundation’s work since its creation in November 2012.
  • Thank you to you, if you’re one of the hundreds who attended CppCon last September and/or one of the scores of volunteers who organized CppCon as a community C++ festival. The primary goal of CppCon was to deliver important information to the community, and so we kept ticket prices low to encourage attendance, we invested in recording all sessions to make them freely available to everyone... and thanks to the strong attendance response and all the volunteering help we got, we still managed to run at a modest profit that we can use both to run CppCon again (registration opens soon, watch this space!) and to invest back into the C++ community including through this new policy.


Remember that the Foundation is not the committee, even though many people and companies participate in both. Rather, the Foundation exists to support the community and the work of the committee while leaving standardization strictly under the C++ committee leadership’s direction. For that reason, this policy leaves it up to the C++ committee leadership as to how the financial support should best be applied. Also, please note that this policy is experimental and subject to revision or withdrawal, but we hope it will be successful in facilitating the work of the committee as we develop the TSes, C++17, and beyond.

The basic idea is that the Foundation will set aside a chunk of money for each meeting, that the convener and main subgroup chairs can draw on to facilitate WG21 work, notably in three areas:

  1. Meeting hosting, when not enough financial support is available.
  2. Travel to a meeting, for authors of important proposals who are not employed by a company and not able to fund it on their own.
  3. Further development of proposals, again when the authors are not employed by a company and not able to self-fund the work fully.

Note that both #2 and #3 are intended to directly help and foster community involvement beyond the big commercial corporations and academic/research institutions.

Recall: For much of the history of the C++ committee, we have had key participants who have made an enormous difference to C++ who have not been funded by a company, university, research lab, or other organization. Today, that hasn't changed: We continue to have some of our major proposals, including at least three large proposed libraries including Ranges (range-based STL using concepts), Networking (based on Boost.ASIO), and 2D Graphics (based on Cairo), that rely partly or entirely on the efforts of such individual world-class experts, and that have been developed to their current state by those experts’ unpaid volunteer efforts.

The committee has expressed strong interest in pursuing all of the three proposals I've just named, as well as others. However, nothing gets done unless someone can contribute sustained heavy work -- and because these key efforts are not funded by companies, some of these efforts likely cannot continue, and cannot be completed, without at least some assistance of the financial variety. We hope that the Foundation can help by starting to offer tactical travel assistance and grant funding for some of the costs of some of these kinds of contributors, so that we can help foster the work that the committee has declared an interest in, but that cannot progress without requiring some level of actual financial development assistance that would not happen if we relied on companies and other institutions alone.

Why a policy?

Since the last November’s standards meeting in particular, the Foundation directors have been working on putting together this policy because the Foundation had already become involved in supporting all three of these categories of standards-related work, but it has been in ad-hoc and on-demand ways as situations have arisen.

For example, even before there was a policy, the Foundation funded work from which the standardization effort is already benefiting at this week's meeting: Without the first grant issued as an initial one-off grant over the winter even before this regular policy became official, we would not now have a 170-page document before us containing near-complete working draft text for applying concepts and ranges to the entire STL iterators and algorithms libraries, along with an open source reference implementation on GitHub – and we do have that and are considering it at this week’s standards meeting.

Since this has worked very well in the form of ad-hoc one-off support, the Foundation directors decided it was time to establish a structure to formalize and regularize this support, and test how well it works more broadly.

So now that we have a policy, what’s different? The answer is, not too much -- the Foundation still wants to support those same things, and this policy mainly gives a regular and consistent structure for doing that. One major difference is that going forward it will be, not just the Foundation’s CEO and directors, but the committee leadership -- the convener and the four main subgroup chairs -- who will decide and approve where the support should be allocated. The Foundation directors will set a budget of what we can contribute toward each meeting, and the committee leadership will decide how they want to use it to promote the work of that meeting. (Note that there is overlap between the Foundation directors and the WG21 leadership, and some of us wear two hats, but the policy is written to distinguish those roles and designed for the long term as the people in particular roles evolve over time.)

Again, this is experimental and subject to review based on how it goes. As we try this out together with the committee subgroup chairs between now and our next meeting in October, we’ll get a better feel together for how it will all work in practice.

Finally, thank you again

Thank you again to the Standard C++ Foundation members at right who directly financially support the work of the Foundation including this initiative.

Thank you again to the CppCon attendees, and to the CppCon volunteers who contribute so much to the running of that conference to disseminate information and support the C++ community, because your support for CppCon feeds back into enabling things like this initiative.

Thank you again to the C++ committee members and leadership who work hard year after year to bring us modern Standard C++ at high quality.

Thank you all, dear readers, for all you do for Standard C++. The Foundation is glad to be able to try to provide some financial support for the good work of C++ standardization in key areas to promote the development of our Technical Specifications, C++17, and beyond, and we look forward with intense interest to see what future results these and other efforts may bring.


N4494: Multidimensional bounds, offset and array_view, rev. 6—Ɓukasz Mendakiewicz, Herb Sutter

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

Date: 2015-05-01

Multidimensional bounds, offset and array_view, revision 6

by Łukasz Mendakiewicz and Herb Sutter


Revision 6 (N4494) incorporates the changes requested by LWG in Cologne meeting, marked as deletions and insertions.

The following suggestions were implemented fully:

  1. Rephrased coord.general avoid references to mathematical entites.
  2. Renamed index to offset.
  3. Changed int Rank template parameter to size_t Rank throughout the document.
  4. Made offset, bounds and bounds_iterator binary operators (apart from @= forms) free functions.
  5. Replaced term "component" with "element" when referring to the individual constituents of offset or bounds.
  6. In coord.bounds.require replaced prose with an equivalent mathematical expression.
  7. In coord.bounds.iterator and coord.bounds.iterator.require removed the requirement on bounds_iterator to represent a random access iterator, replacing with "as-if" phrasing.
  8. In the description of bounds_iterator& operator++() replaced the code snippet with equivalent prose.
  9. In views.general changed the font back to non-monospace.
  10. Removed views.require, duplicating it as arrayview.require and stridedarrayview.require.
  11. Removed redundant assignment operators on array_view and strided_array_view.
  12. Employed "exposition only" data members is the descriptions of array_view and strided_array_view semantics.
  13. Rephrased the first paragraph in arrayview.cons to avoid ambiguity in binding of the token "type".
  14. In constexpr array_view(Viewable&& vw) rephrased the third bullet point.
The following suggestion was implemented partially:
  1. Instead of the array_view(ArrayType& arr) constructor being completely removed, it has been constrained to 1-D case as the Committee indicated that such case does not exhibit the undefined behavior. We believe that the request to remove it completely was a misstatment.

The following suggestion was not implemented:

  1. The semantics of the proposed types were not extended to allow rank-0 cases. We feel that we lack sufficient practical experience in using such cases and we are afraid of some contention points when it comes to defining their detailed semantics. We observe that such an extension can be introduced in future without conflicting with the proposal in the current form.

N4487: Constexpr Lambda—Faisal Vali, Ville Voutilainen, 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: N4487

Date: 2015-04-28

Constexpr Lambda

by Faisal Vali, Ville Voutilainen, Gabriel Dos Reis


This proposal suggests allowing lambda-expressions in constant expressions, removing an existing restriction. The authors propose that certain lambda-expressions and operations on certain closure objects be allowed to appear within constant expressions. In doing so, we also propose that a closure type be considered a literal type if the type of each of its data-members is a literal type; and, that if the constexpr specifier is omitted within the lambda-declarator, that the generated function call operator be constexpr if it would satisfy the requirements of a constexpr function (similar to the constexpr inference that already occurs for implicitly defined constructors and the assignment operator functions).

Thoughts About C++17—Bjarne Stroustrup

We normally wait until committee papers get "N" (permanent) numbers, but this one is an exception. It has also already been circulated to ISO C++ committee members in preparation for the next ISO C++ meeting that begins on Monday in Lenexa, Kansas, USA.

D4492: Thoughts About C++17

by Bjarne Stroustrup

From the paper:

This is a draft intended to focus a discussion at the Lexena committee meeting.

This is an extended version (based on feedback) of an internal committee standard reflector message that got so widely distributed and discussed that it would be a good idea to have it as a document. I have tried to remove distracting committee jargon. Thanks to people who took part in the reflector discussion or commented on the web. I have also added links. It is still a collection of thoughts aimed at stimulating a discussion, rather than a formal paper or a precise proposal.

The note was written for committee members, but “escaped into the wild.” Here are a few comments from the web: [Reddit] [The Register] [Hacker News]

As you see, people outside the committee also have strong opinions. Those opinions can depart radically from the ones I hear in the committee and from reality.

I am often asked “what will C++17 be?” and variations of “What will C++17 do for me?” ... [continue reading]

N4402: Resumable Functions (revision 4)—Gor Nishanov, Jim Radigan

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

Date: 2015-03-31

Resumable Functions (revision 4)

by Gor Nishanov, Jim Radigan


Revisions and History

This document supersedes N4286. Changes relative to N4286 include:

  • renaming customization points back to resumable_traits and resumable_handle as they were in N4134;
  • changing requirements on the return type of initial_suspend() and final_suspend() to be lexically convertible to bool;
  • changing requirements on the return type of yield_value() to be either of a void type or a type lexically convertible to bool;
  • making a set_result member function optional in a promise type; the absence of a set_result indicates that resumable function does not support an eventual return value and using await operator or for-await statement is not allowed in resumable functions with such promise;
  • altered cancellation mechanism in resumable functions; instead of using cancellation_requested() member function in a promise to indicate that on the next resume resumable function need to be cancelled, an explicit member function destroy() is added to the resumable_handle. A destroy() member function can be invoked to force resumption of coroutine to go on the cancel path;
  • added resume(), destroy(), and done() member functions to resumable_handle;
  • moved proposed wording into a separate document N4302;
  • removed trivial awaitables suspend_always, suspend_never and suspend_if; switching yield_value, initial_suspend, and final_suspend to return bool eliminated the need for those;

Terms and Definitions


A generalized routine that in addition to traditional subroutine operations such as invoke and return supports suspend and resume operations.


2015-04 pre-Lenexa mailing available

The 2015-04 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
N4381 Suggested Design for Customization Points Eric Niebler 2015-03-11 2015-04   Library  
N4382 Working Draft, C++ extensions for Ranges Eric Niebler 2015-04-12 2015-04   Library  
N4383 C++ Standard Library Active Issues List (Revision R92) Marshall Clow 2015-04-10 2015-04   Library  
N4384 C++ Standard Library Defect Report List (Revision R92) Marshall Clow 2015-04-10 2015-04   Library  
N4385 C++ Standard Library Closed Issues List (Revision R92) Marshall Clow 2015-04-10 2015-04   Library  
N4386 Unspecialized std::tuple_size should be defined Nevin Liber 2015-02-24 2015-04   Library  
N4387 Improving pair and tuple, revision 3 Daniel Krügler, Geoffrey Romer, Ville Voutilainen 2015-03-14 2015-04 N4064 Library  
N4388 A Proposal to Add a Const-Propagating Wrapper to the Standard Library Jonathan Coe, Robert Mill 2015-02-25 2015-04 N4372 Library  
N4389 Wording for bool_constant, revision 1 Zhihao Yuan 2015-02-23 2015-04 N4334 Library  
N4390 Minimal incomplete type support for standard containers, revision 3 Zhihao Yuan 2015-02-24 2015-04 N4371 Library  
N4391 make_array, revision 4 Zhihao Yuan 2015-02-26 2015-04 N4315 Library  
N4392 C++ Latches and Barriers Alasdair Mackintosh, Olivier Giroux 2015-03-03 2015-04 N4204 Library  
N4393 Noop Constructors and Destructors Pablo Halpern 2015-04-10 2015-04   Evolution  
N4394 Agenda for Lenexa Meeting Clark Nelson 2015-03-12 2015-04      
N4395 SIMD Types: ABI Considerations Matthias Kretz 2015-04-10 2015-04   Concurrency/Library  
N4396 National Body Comments: PDTS 19841, Transactional Memory Barry Hedquist 2015-03-16 2015-04   Transactional Memory  
N4397 A low-level API for stackful coroutines Oliver Kowalke 2015-04-09 2015-04 N3985 Concurrency  
N4398 A unified syntax for stackless and stackful coroutines Oliver Kowalke 2015-04-09 2015-04   Concurrency  
N4399 Proposed Working Draft, Technical Specification for C++ Extensions for Concurrency Artur Laksberg 2015-04-10 2015-04 N4107 Concurrency  
N4400 Concurrency TS Editor's Report, May 2015 Artur Laksberg 2015-04-10 2015-04   Concurrency  
N4401 Defaulted comparison operator semantics should be uniform Michael Price 2015-04-07 2015-04   Evolution  
N4402 Resumable Functions (revision 4) Gor Nishanov   missing   Evolution  
N4403 Draft Wording for Resumable Functions Gor Nishanov   missing   Evolution  
N4404 Extension to aggregate initialization Oleg Smolsky 2015-03-31 2015-04   Evolution  
N4405 Type of the accumulaters of standard algorithms std::accumulate and std::inner_product Vladimir Grigoriev 2015-02-11 2015-04   Library Evolution  
N4406 Integrating Executors with Parallel Algorithm Execution Jared Hoberock, Michael Garland, Oliver Giroux 2015-04-10 2015-04   Concurrency  
N4407 Working Draft, Technical Specification for C++ Extensions for Parallelism Jared Hoberock 2015-04-10 2015-04   Concurrency  
N4408 Parallelism TS Editor's Report Jared Hoberock 2015-04-10 2015-04   Concurrency  
N4409 Programming Languages -- Technical Specification for C++ Extensions for Parallelism Jared Hoberock 2015-04-10 2015-04   Concurrency  
N4410 Responses to PDTS comments on Transactional Memory Jens Maurer 2015-04-09 2015-04   Transactional Memory  
N4411 Task Block (formerly Task Region) R4 Pablo Halpern, Arch Robison, Hong Hong, Artur Laksberg, Gor Nishanov, Herb Sutter 2015-04-10 2015-04   Library Evolution, Concurrency  
N4412 Shortcomings of iostreams Jens Maurer 2015-04-09 2015-04   Library  
N4413 Constexpr Lambas Faisal Vali   missing   Evolution  
N4414 Executors and Schedulers Revision 5 Chris Mysen 2015-04-10 2015-04 N4143 Concurrency  
N4415 Simple Contracts for C++ Gabriel Dos Reis, J. Daniel Garcia, Francesco Logozzo, Manuel Fahndrich, Shuvendu Lahri 2015-04-12 2015-04   Evolution  
N4416 Don't Move: Vector Can Have Your Non-Moveable Types Covered Nevin Liber 2015-04-09 2015-04   Library Evolution  
N4417 Source-Code Information Capture Robert Douglas 2015-04-08 2015-04 N4129 Reflection  
N4418 Parameter Stringization Robert Douglas 2015-04-08 2015-04   Reflection  
N4419 Potential extensions to Source-Code Information Capture Robert Douglas 2015-04-08 2015-04   Reflection  
N4420 Defining Test Code Robert Douglas 2015-04-08 2015-04   Reflection  
N4421 Evolution Active Issues List (Revision R11) Ville Voutilainen 2015-04-10 2015-04      
N4422 Evolution Completed Issues List (Revision R11) Ville Voutilainen 2015-04-10 2015-04      
N4423 Evolution Closed Issues List (Revision R11) Ville Voutilainen 2015-04-10 2015-04      
N4424 Inline Variables Hal Finkel, Richard Smith 2015-04-07 2015-04   Evolution  
N4425 Generalized Dynamic Assumptions Hal Finkel 2015-04-07 2015-04   Evolution  
N4426 Adding [nothrow-] swappable traits Daniel Krügler 2015-04-10 2015-04   Library  
N4427 Agenda and Meeting Notice for WG21 Pre-Lenexa Telecon Meeting Herb Sutter 2015-04-08 2015-04      
N4428 Type Property Queries (rev 4) Andrew Tomazos, Christian Kaeser 2015-04-08 2015-04 N4113 Reflection  
N4429 Core issue 1941 - rewording inherited constructors Richard Smith 2015-04-10 2015-04   Evolution  
N4430 Core issue 1776 - replacement of class objects containing reference members Richard Smith 2015-04-10 2015-04 N4303 Core  
N4431 Working Draft, Standard for Programming Language C++ Richard Smith 2015-04-10 2015-04 N4296    
N4432 Editor's Report -- Working Draft, Standard for Programming Language C++ Richard Smith 2015-04-10 2015-04      
N4433 Flexible static_assert messages Michael Price 2015-04-09 2015-04   Evolution  
N4434 Tweaks to Streamline Concepts Lite Syntax Walter Brown 2015-04-10 2015-04   Evolution  
N4435 Proposing Contract Attributes Walter Brown 2015-04-09 2015-04   Evolution  
N4436 Proposing Standard Library Support for the C++ Detection Idiom Walter Brown 2015-04-09 2015-04   Library Evolution  
N4437 Conditionally-supported Special Math Functions, v3 Walter Brown 2015-04-09 2015-04 N3743 Library Evolution  
N4438 Industrial Experience with Transactional Memory at Wyatt Technologies. Brett Hall 2015-04-09 2015-04   Transactional Memory  
N4439 Light-Weight Execution Agents Revision 3 Torvald Riegel 2015-04-10 2015-04 N4156 Concurrency  
N4440 Feature-testing recommendations for C++ Clark Nelson 2014-04-10 2015-04 N4200 Feature Testing  
N4441 SG5: Transactional Memory (TM) Meeting Minutes 2015-03-23 and 2015-04-06 Michael Wong 2015-04-10 2015-04   Transactional Memory  
N4442 Default argument for second parameter of std::advance (Rev. 1) Vladimir Grigoriev 2015-04-09 2015-04 N4369 Library Evolution  
N4443 Introducing alias size_type for type size_t in class std::bitset (Rev. 1 ) Vladimir Grigoriev 2015-04-09 2015-04 N4368 Library Evolution  
N4444 Linux-Kernel Memory Model Paul E. McKenney 2015-04-10 2015-04 N4374 Concurrency  
N4445 Overly attached promise Agustín Bergé, Hartmut Kaiser 2015-04-09 2015-04   Concurrency  
N4446 The missing INVOKE related trait Agustín Bergé 2015-04-09 2015-04   Library Evolution  
N4447 From a type T, gather members name and type information, via variadic template expansion Cleiton Santoia Silva, Daniel Auresco 2015-04-10 2015-04 N3987 Reflection  
N4448 Rounding and Overflow in C++ Lawrence Crowl 2015-04-12 2015-04   Library Evolution  
N4449 Message Digest Library for C++ Zhihao Yuan 2015-04-09 2015-04   Library Evolution  
N4450 Variant: a typesafe union (v2) Axel Naumann 2015-04-13 2015-04 N4218 Library Evolution  
N4451 Static reflection Matúš Chochlík 2014-04-11 2015-04 N4111 Reflection  
N4452 Use cases of reflection Matúš Chochlík 2014-04-11 2015-04   Reflection  
N4453 Resumable Expressions Christopher Kohlhoff 2015-04-12 2015-04   Evolution  
N4454 SIMD Types Example: Matrix Multiplication Matthias Kretz 2015-04-10 2015-04   Concurrency  
N4455 No Sane Compiler Would Optimize Atomics JF Bastien 2015-04-10 2015-04   Concurrency  
N4456 Towards improved support for games, graphics, real-time, low latency, embedded systems Michael Wong 2015-04-12 2015-04   Evolution  
N4457 C++ Standard Core Language Active Issues, Revision 93 William M. Miller 2015-04-13 2015-04      
N4458 C++ Standard Core Language Defect Reports and Accepted Issues, Revision 93 William M. Miller 2015-04-13 2015-04      
N4459 C++ Standard Core Language Closed Issues, Revision 93 William M. Miller 2015-04-13 2015-04      
N4460 LWG 2424: Atomics, mutexes and condition variables should not be trivially copyable Ville Voutilainen 2015-04-07 2015-04   Evolution  
N4461 Static if resurrected Ville Voutilainen 2015-04-07 2015-04   Evolution  
N4462 LWG 2089, Towards more perfect forwarding Ville Voutilainen 2015-04-07 2015-04   Evolution  
N4463 IO device requirements for C++ Cleiton Santoia Silva, Daniel Auresco 2015-04-10 2015-04   I/O  
N4464 Pi-calculus syntax for C++ executors Cleiton Santoia Silva 2015-04-10 2015-04   Concurrency  
N4465 A Module System for C++ (Revision 3) Gabriel Dos Reis, Mark Hall, Gor Nishanov 2015-04-13 2015-04   Evolution  
N4466 Wording for Modules Gabriel Dos Reis 2015-04-13 2015-04   Evolution  
N4467 C++ Modules: Directions and Issues Gabriel Dos Reis   missing   Evolution  
N4468 On Quantifying Memory-Allocation Strategies John Lakos, Jeffrey Mendelsohn, Alisdair Meredith, Nathan Myers 2015-04-11 2015-04   Library Evolution  
N4469 Template Argument Type Deduction James Touton, Mike Spertus 2015-04-10 2015-04 N3601 Evolution  
N4470 Variadic lock_guard Mike Spertus 2015-04-10 2015-04   Concurrency  
N4471 Template parameter deduction for constructors (Rev 2) Mike Spertus 2015-04-12 2015-04 N3602 Evolution  
N4472 consexpr goto Ville Voutilainen 2015-04-10 2015-04   Evolution  
N4473 noexcept(auto), again Ville Voutilainen 2015-04-10 2015-04   Evolution  
N4474 Unified Call Syntax: x.f(y) and f(x,y) Bjarne Stroustrup, Herb Sutter 2015-04-12 2015-04   Evolution  
N4475 Default comparisons (R2) Bjarne Stroustrup 2015-04-09 2015-04 N4175 Evolution  
N4476 Thoughts about Comparisons (R2) Bjarne Stroustrup 2015-04-09 2015-04   Evolution  
N4477 Operator Dot (R2) Bjarne Stroustrup, Gabriel Dos Reis 2015-04-09 2015-04 N4173 Evolution  
N4478 Networking Library Proposal (Revision 5 Christopher Kohlhoff 2015-04-13 2015-04 N4370 Library Evoution  
N4479 Merge Fundamentals V1 into v2 Jeffrey Yasskin 2015-04-12 2015-04   Library Evoution  
N4480 Programming Languages -- C++ Extensions for Library Fundamentals DTS Jeffrey Yasskin 2015-04-07 2015-04      
N4481 Working Draft, C++ Extensions for Library Fundamentals, Version 2 Jeffrey Yasskin 2015-04-12 2015-04 N4336 Library Evolution  
N4482 Some notes on executors and the Networking Library Proposal Christopher Kohlhoff 2015-04-13 2015-04   Concurrency  

N4394: PL22.16/WG21 draft agenda: 4-9 May 2015, Lenexa KS/US—Clark Nelson

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

Date: 2015-03-12

PL22.16/WG21 draft agenda: 4-9 May 2015, Lenexa KS/US

by Clark Nelson


At this meeting we will address ballot comments on the Transactional Memory PDTS (N4302), and discuss whatever comments are available on the Concepts PDTS (N4377). We also aim to bring several projects to their next ballot stage, potentially including the following:

  • Library Fundamentals 2 (prospective WD N4336)
  • Concurrency (proposal N4313)
  • Networking (proposal N4370)

N4388: A Proposal to Add a Const-Propagating Wrapper to the Standard Library—J Coe, R Mill

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

Date: 2015-02-25

A Proposal to Add a Const-Propagating Wrapper to the Standard Library

by Jonathan Coe, Robert Mill


We propose the introduction of a propagate_const wrapper class that propagates const-ness to pointer-like member variables. ... The behaviour of const member functions on objects with pointer-like data members is seen to be surprising by many experienced C++ developers. A const member function can call non-const functions on pointer-like data members and will do so by default without use of const_cast...