C++ Proposals please...
A quick overview over the newest mailing of proposals for the upcoming C++ Committee Meeting in Kona, Hawaii. With C++17 being "done" but not yet an official standard, its a good time to start new proposals aiming for C++20 and beyond. After all, a new proposal which might needs to go through a TS might not make it to the C++20 timeframe...
You find the full list of proposals here.
These are the mature proposals that are a TS or related to one:
- Working Draft Extensions to C++ for Modules
- Working Draft C++ extensions for Concepts
- Concepts TS revisited
- Concepts: The Future of Generic Programming
- Standard Library Modules
- no papers on other TS like the Network TS.
Proposals of new things into Standard C++
Adding factories and scope_exit, scope_sucess and scope_fail to C++. make_scope_* takes a lambda which will be executed in the context.
SG14 proposing a ring span type for the standard library. Proposed is std::ring_span<class T, class popper = default_popper<T> > with null_popper and copy_popper as alternatives. The elements are stored in contiguous memory, the ring is of fixed size. The ring span does not own memory, avoiding allocations which would be needed with std::queue. It offers the interface of an std::queue, as that is the currently offered standard solution. This is an excellent paper, with a very limited focus on a single, simple container like type.
This paper adds the $ sign to the C++ standard, for the purpose of reflection. e.g. $reflect will be a thing soon. This can be found under <experimental/reflect>, and as it seems Enums, Classes, Unions, Types, Aliases, Namespaces, (member) variables and enumerators seem to be reflectable, e.g $reflect(_) will work on these. But, if you are interested in reflection, you might want to reflect on the paper it self.
Proposing vector types for SIMD programming. The paper aims at being a starting point, rather then a complete solution.
A simple 2d drawing API for C++ takes slowly shape. With 183 pages this is a complex paper dealing with completly new field for C++: drawing on a surface. This seems currently not to include text rendering.
The proposal handles mangled types only, the proposed class has the name mangled_library. You are able to load functions via get<void(int)>("foo::bar") member function. The library builds upon std::filesystem for path usage.
What about timezones? This paper aims at making minimal changes to <chrono> in order to add support for calender (gregorian) and timezones. The scope is realtively small, only one calendar (gregorian) is actually proposed, while others could be implemented easily, the paper mentions the coptic calendar.
More on reflection, this paper might be a better read then the first one, as it aims to provide a rationale behind the proposed design.
Executors are an important step towards parallelism in the C++ Standard. So it is good to see that this is taking shape. This image gives you a good overview on the proposed types:
This is an interesting paper from SG14. From the paper:
Colony is a higher[-]performance container for situations where the ratio of insertions/erasures to iterations is relatively high. It is unordered but sortable, allows for both fast iteration and direct pointer linkage, and does not invalidate pointers/iterators to non[-] erased elements during insertion or erasure. It also frees or reuses unused memory on the fly, and is it's own abstract data type; similar to a "bag", "bucket[-]array" or "unordered multiset" but without key values.
Based on this description, I'm not sure if colony is able to write a declaration of independence or not ;)
Proposing a Read, Copy, Update API for C++, also reviewing the existing ones in C. The paper contains the design for a few types handling the RCU related talks in a clean and modern C++ way.
#pragma once, while widely used, is not in the standard. This paper proposes to add a replacement for #pragma once with #once and also #forget. Where #once identifier is the replacement for the include guard/#pragma, and #forget identifier is similar to #undef.
This is a unique paper, the authors goal is to add contracts to the C++ language by using attributes. Paper includes wording and a few examples.
This is a very important paper, its goals are to lay down the principles on which the C++ standard should operate on. This document is a starting point for this.
Towards Better Embedded programming support for C++ and an update on the status of SG14, 2 years later
Interesting read on what SG14 has accomplished in the last two years, and how to have better support for embedded in C++.
The TL;DR version and maybe best starting point for understanding the proposed static reflection for C++.
Herb Sutter and Andrew Sutton weigh in on the static reflection debate. This paper shows how an object level reflection can provide a better meta programming not based on TMP, rather then an type-level only reflection.
To boldy go where no C++ programmer... This paper is written by a very experienced committee member, and hence can be seen as a first blue print for C++20. Yet, history has shown, that expectations on new standards are often to high. But the aim of having Modules, Conceptes, Ranges and Networking in C++20 would be something worth fighting for. With higher attendance and more activity in the committee, the needed resouces to achive this goal could be there.
And one more paper on reflection. This time aiming at the fact that with constexpr, values don't have to be types:
P0194R2 proposes adding compile-time reflection facilities to the language. I’m looking forward to the capabilities themselves, but I’m concerned about using types to perform computations when we’ve come such a long way in providing efficient compile-time computation facilities through
constexpr. Let’s design with modern C++ in mind and leave the template metaprogramming shackles of the past behind.
Even more Proposals...
There is more proposals, but I decided to focus mostly on proposals on future standards, new ideas. There is also lots of interesting reads on ways to improve or add to the current standard.
Join the Meeting C++ patreon community!
This and other posts on Meeting C++ are enabled by my supporters on patreon!