-
Stay up-to-date with everything C++! Content directly fetched from the subreddit just for you. Join our group for discussions : @programminginc Powered by : @r_channels
Trip Report: Freestanding in St. Louis
WG21 just held its summer meeting in St. Louis, Missouri, USA.
There were big topics discussed, including reflection, contracts, std::execution, and borrow checking.
I spent roughly a day co-chairing in the Safety and Security (SG23) study group, and most of the rest of my time in LEWG co-chairing.
# [P2996 Reflection](https://wg21.link/P2996R4)
EWG forwarded its parts of reflections to CWG this meeting.
LEWG continued its review of the `std::meta::info` class interface.
One of the contentions questions that came up in LEWG was what to do with `meta::name_of` when the referenced entity can't have a name, or perhaps doesn't have a name.
Going into the review, the paper had `meta::name_of` return an empty `string_view` if the entity was nameless.
Sometimes that's the right answer.
There were requests to have `meta::name_of` error / fail to be a constant expression when the entity was nameless (e.g. `meta::name_of(^3)`).
This would help users notice when they had made a category error of feeding a nameless thing to `name_of`, but it would be irritating when working with things that could potentially have names, but don't, like anonymous unions, lambdas / closures, and parameter names.
There were discussions about returning `optional<string_view>` as well.
Eventually, we landed on failing to be a constant expression if the entity can't have a name, and returning an empty string_view if the entity could have a name, but doesn't.
In the reflection study group, I got to review one of my papers.
Reflection currently has `std::vector` in many key interfaces, but `std::vector` isn't available in freestanding.
With the current design of freestanding, `std::vector` shouldn't be available at runtime since it allocates memory and throws exceptions.
Neither of those are a problem at compile time though.
So [P3295: Freestanding constexpr containers and constexpr exception types](https://wg21.link/P3295R0) addresses this by making `std::vector` consteval on freestanding implementations.
This keeps exceptions and allocations out of runtime, while still allowing reflection to work reasonably at build time.
`std::vector` isn't a totally isolated facility though, so I ended up expanding the scope to bring along `std::allocator`, `std::string`, some exceptions from `<stdexcept>`, and some methods on `std::string_view` too.
There were a few other papers that went through LEWG that also expand the scope of constexpr. Both [atomics](https://wg21.link/P3309) and [exceptions](https://P3068) have papers in flight that will allow their use in constant expressions.
# [P2300 std::execution](https://wg21.link/p2300) (AKA senders and receivers)
P2300 is part of C++26 now! This has been an enormous effort from the authors, LEWG, and LWG to get P2300 ready for the standard, and now it is in.
There's a bunch of work that still needs to happen to make the new facilities easier for users.
Work is ongoing with [async_scope](https://wg21.link/P3149), [system execution context](https://wg21.link/P2079), and a general coroutine task type.
There are legitimate concerns about the complexity of P2300.
The expectation is that users won't be exposed to most of the complexity in practice, as most of that code is plumbing and metaprogramming.
# Safety and Security (SG23)
Erroneous behavior ([P2795R5 Erroneous behaviour for uninitialized reads](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2795r5.html))was added as a new category of behavior in the Tokyo 2024 meeting. It's a specification technique that lets us define the outcome of an operation, while still allowing the toolchain to diagnose that the behavior is wrong. This specification technique could be the path forward to addressing many instances of undefined behavior in the standard, so that they don't permit optimizers to completely wreck programs with mistakes in them.
In St. Louis, SG23 forwarded [User-defined erroneous behaviour](https://wg21.link/P3232) to the main design groups. This defines a function `std::erroneous` that is always
C++ Show and Tell - July 2024
Use this thread to share anything you've written in C++. This includes:
* a tool you've written
* a game you've been working on
* your first non-trivial C++ program
The rules of this thread are very straight forward:
* The project must involve C++ in some way.
* It must be something you (alone or with others) have done.
* Please share a link, if applicable.
* Please post images, if applicable.
If you're working on a C++ library, you can also share new releases or major updates in a dedicated post as before. The line we're drawing is between "written in C++" and "useful for C++ programmers specifically". If you're writing a C++ library or tool for C++ developers, that's something C++ programmers can use and is on-topic for a main submission. It's different if you're just using C++ to implement a generic program that isn't specifically about C++: you're free to share it here, but it wouldn't quite fit as a standalone post.
Last month's thread: https://www.reddit.com/r/cpp/comments/1d6zoku/c_show_and_tell_june_2024/
https://redd.it/1dy404d
@r_cpp
My VS is tripping
It give me random errors, anyone know better code studios than Visual Studios?
https://redd.it/1dxy7xn
@r_cpp
Mac as main PC?
Hello everyone, I would like to know what disadvantages there will be when developing C++ on Mac OS?
And will there be any at all?
Except for OpenGL of course.
https://redd.it/1dxf819
@r_cpp
TIL: std::pow(2.0f, 2); returns double!
I didn't expect that!
To force it return float you must use either
std::pow(2.0f, 2.0f);
or
std::powf(2.0f, 2);
Tested with MSVC and Xcode
https://redd.it/1dxcizw
@r_cpp
What color scheme do you use in your IDE?
This is one of those things that maybe sounds silly at first, but when one is staring at code for hours on end, it really does matter.
I've been running Darcula (in CLion) for several years and last night my eyes had finally had enough and I went spelunking for something better. What I found was mostly a collection of angry fruit salad intermixed with some of the ugliest color schemes I've ever seen.
I'm trying the Asteria color scheme currently (adding more and more custom modifications as I go), and while it's excessively purple, it's leaps and bounds better than other schemes I was browsing through. Still going to take a lot of tweaking over time before I can decide if I want to stick with it, or abandon it for something else.
And this got me curious -- what color schemes are you all running these days? What do you stare at for untold hours of coding?
https://redd.it/1dwvu16
@r_cpp
Memory Safety in C++ vs Rust vs Zig
shyamsundarb/memory-safety-in-c-vs-rust-vs-zig-f78fa903f41e" rel="nofollow">https://medium.com/@shyamsundarb/memory-safety-in-c-vs-rust-vs-zig-f78fa903f41e
https://redd.it/1dwpnyf
@r_cpp
A 16-byte std::function implementation.
I had this code around for a while but just didn't want to spam this thread since my last post was also about std::function.
In case you need something that uses up less space. This is not a full implementation but can be used as a reference for implementing your own.
Latest GCC and Clang compilers takes up 32 bytes while MSCV takes up 64 bytes.
The trick lies within `struct lambda_handler_result;` and `lambda_handler_result (*lambda_handler)(void*, void**) {nullptr};` `lambda_handler_result` holds the functions that free, copy and call the lambda. We don't have to store a variable for this but we can still get the handling functions from a temporary through `lambda_handler`and this is how space is saved.
template<typename T>
struct sfunc;
template<typename R, typename ...Args>
struct sfunc<R(Args...)>
{
struct lambda_handler_result
{
void* funcs[3];
};
enum class tag
{
free,
copy,
call
};
lambda_handler_result (*lambda_handler)(void*, void**) {nullptr};
void* lambda {nullptr};
template<typename F>
sfunc(F f)
{
*this = f;
}
sfunc() {}
sfunc(const sfunc& f)
{
*this = f;
}
sfunc(sfunc&& f)
{
*this = f;
}
sfunc& operator = (sfunc&& f)
{
if(&f == this){
return *this;
}
lambda_handler = f.lambda_handler;
lambda = f.lambda;
f.lambda_handler = nullptr;
f.lambda = nullptr;
return *this;
}
void free_lambda()
{
if(lambda_handler)
{
auto ff {lambda_handler(lambda, nullptr).funcs[(int)tag::free]};
if(ff){
((void(*)(void*))ff)(lambda);
}
}
lambda = nullptr;
}
sfunc& operator = (const sfunc& f)
{
if(&f == this){
return *this;
}
free_lambda();
lambda_handler = f.lambda_handler;
if(f.lambda)
{
auto ff {lambda_handler(lambda, nullptr).funcs[(int)tag::copy]};
if(ff){
((void(*)(void*, void**))ff)(f.lambda, &lambda);
}
else{
lambda = f.lambda;
}
}
return *this;
}
template<typename ...>
struct is_function_pointer;
template<typename T>
struct is_function_pointer<T>
{
static constexpr bool value {false};
};
template<typename T, typename ...Ts>
struct is_function_pointer<T(*)(Ts...)>
{
static constexpr bool value {true};
};
template<typename F>
auto operator = (F f)
{
if constexpr(is_function_pointer<F>::value == true)
{
free_lambda();
lambda = (void*)f;
lambda_handler = [](void* l, void**)
{
return lambda_handler_result{{nullptr, nullptr, (void*)+[](void* l, Args... args)
{
auto& f {*(F)l};
return f(forward<Args>(args)...);
}}};
};
}
else
{
free_lambda();
lambda = {new F{f}};
lambda_handler = [](void* d, void** v)
{
return lambda_handler_result{{(void*)[](void*d){ delete (F*)d;},
(void*)[](void*d, void** v){ *v = new F{*((F*)d)};},
(void*)[](void* l, Args... args)
{
then adopted the paper “[P3328R0](https://wg21.link/P3328R0): Observable Checkpoints During Contract Evaluation” (on top of [P2900R7](https://wg21.link/P2900R7), [P1494R3](https://wg21.link/P1494R3)), making contract assertions observable, and therefore more robust to undefined behaviour.
* Following that, we had a productive discussion on contract assertions on function pointers ([P3250R0](https://wg21.link/P3250R0), [P3271R0](https://wg21.link/P3271R0)) which will need more work
* We had a productive discussion on “[P3097R0](https://wg21.link/P3097R0): Contracts for C++: Support for Virtual Functions” which ended in SG21 adopting the design proposed by that paper, which was then also approved by EWG on Friday, thereby plugging the most significant remaining design hole in P2900.
* We also discussed some extensions to P2900 aimed at facilitating migration from existing macro-based facilities to contracts ([P3290R0](https://wg21.link/P3290R0), [P3311R0](https://wg21.link/P3311R0)).
* Finally, we discussed a few other papers proposing changes to P2900, rejecting “[P3316R0](https://wg21.link/P3316R0): A more predictable unchecked semantic” and not finishing discussion on two more ([P3210R0](https://wg21.link/P3210R0), [P3249R0](https://wg21.link/P3249R0)) because we ran out of time.
We will continue regular telecons in the lead-up to the next WG21 meeting in Wrocław in November. During those, we will focus on the remaining issues with P2900: constification, pre/post on function pointers, pre/post on coroutines, and any other papers proposing breaking changes to the MVP.
*****
### C / C++ Liaison Group (SG22) Progress
*****
SG22 did not meet in person during St. Louis. We continue to run telecons by demand and provide feedback through the mailing list.
*****
### Safety & Security Group (SG23) Progress
*****
SG23 met for one day during St. Louis.
#### Papers forwarded
* [P3232R0](https://wg21.link/P3232R0): User-defined erroneous behaviour - proposes the `erroneous()` function that always invokes erroneous() behavior, much like `unreachable()` invokes undefined behavior.
#### Papers reviewed
* [P3274R0](https://wg21.link/P3274R0): A framework for Profiles development - SG23 took a poll and determined that there was greater support for the attribute-like syntax for profile directives.
* [P3297R0](https://wg21.link/P3297R0): C++26 Needs Contract Checking - SG23 took a poll and determined that there was a preference to have contracts in C++26 rather than no contracts, even if it means watering down contracts to some degree.
* (no paper): Safe C++ / Borrow Checking - Sean Baxter presented his borrow checking work in Circle. There was strong consensus for spending more committee time on borrow checking.
*****
# C++ Release Schedule
*****
***NOTE: This is a plan not a promise. Treat it as speculative and tentative.***
***See [P1000](https://wg21.link/P1000), [P0592](https://wg21.link/P0592), [P2000](https://wg21.link/P2000) for the latest plan.***
Meeting | Location | Objective
-|-|-
~~2023 Summer Meeting~~ | ~~Varna 🇧🇬~~ | ~~First meeting of C++26.~~
~~2023 Fall Meeting~~ | ~~Kona 🇺🇸~~ | ~~Design major C++26 features.~~
~~2024 Winter Meeting~~ | ~~Japan 🇯🇵~~ | ~~Design major C++26 features.~~
**2024 Summer Meeting** | **St. Louis 🇺🇸** | **Design major C++26 features.**
2024 Fall Meeting | Wrocław 🇵🇱 | C++26 major language feature freeze.
2025 Winter Meeting | Hagenberg 🇦🇹 | C++26 feature freeze. C++26 design is feature-complete.
2025 Summer Meeting | Sofia 🇧🇬 | Complete C++26 CD wording. Start C++26 CD balloting ("beta testing").
2025 Fall Meeting | Kona 🇺🇸 | C++26 CD ballot comment resolution ("bug fixes").
2026 Winter Meeting | 🗺️ | C++26 CD ballot comment resolution ("bug fixes"), C++26 completed.
2026 Summer Meeting | 🗺️ | First meeting of C++29.
*****
# Status of Major C++ Feature Development
*****
***NOTE: This is a plan not a promise. Treat it as speculative and tentative.***
* IS = International Standard. The C++
forwarded to LEWG but needs to return to SG1 to discuss one outstanding concurrency issue.
(Note R10 will be in post-mailing).
* [P2849R0](https://wg21.link/P2849R0): async-object - aka async-RAII - proposes a pattern for defining objects
that have async lifetime (async construction and/or destruction).
* [P3300R0](https://wg21.link/P3300R0): C++ Asynchronous Parallel Algorithms - explores the design space of
defining composable asynchronous parallel algorithms using sender/receiver.
* [P3296R1](https://wg21.link/P3296R1): let_async_scope - proposes a sender algorithm that makes it easier to
safely use an async_scope for eagerly launching work.
*****
### Networking (SG4) Progress
*****
Networking Study Group did not meet in person during St. Louis.
We hold telecons as required. Our main focus is on Networking proposals based on P2300.
*****
### Numerics Study Group (SG6) Progress
*****
The numerics group met for one day. We reviewed 5 papers.
#### Papers forwarded to LEWG
* ✅ [P3306R0](https://wg21.link/P3306R0): Atomic Read-Modify-Write Improvements
* ✅ [P3111R0](https://wg21.link/P3111R0): Atomic Reduction Operations
#### Papers reviewed (require more work)
* ❤️ [P3045R1](https://wg21.link/P3045R1): Quantities and units library - needs more time but we're trying to converge on how we want to chunk our workload.
* ❤️ [P2964R1](https://wg21.link/P2964R1): Allowing user-defined types in std::simd - We agree with the direction the paper is taking and encouraged further work.
* ❤️ [P3161R1](https://wg21.link/P3161R1): Unified integer overflow arithmetic - prompted a discussion about completing the set of functions that was started with saturating functions and “[P3018R0](https://wg21.link/P3018R0): Low-Level Integer Arithmetic”. We hope to see a combined paper in the future.
*****
### Compile-time Programming Study Group (SG7) Progress
*****
We saw 7 papers and forwarded 6 of them, most of these are extensions for “[P2996R3](https://wg21.link/p2996r3): Reflection for C++26”
#### Papers forwarded to EWG
* ✅ [P3294R0](https://wg21.link/p3294r0): Code Injection with Token Sequences - exploring different ways of injection (AST manipulation, string based, fragment based) and proposing token based.
* ✅ [P2825R2](https://wg21.link/p2825r2): declcall (unevaluated-postfix-expressions) * a mechanism to obtain function pointer from expression with exactly same mechanism as call overloading works.
* ✅ [P3289R0](https://wg21.link/p3289r0): consteval blocks - a mechanism to write immediately evaluated code for generative reflection.
* ✅ [P3273R0](https://wg21.link/P3273R0): Introspection of Closure Types - extension to reflection allowing introspection of closure types and their captures.
* ✅ [P3293R0](https://wg21.link/P3293R0): splicing a base class subobject - creating a way how to splice base class objects in same way as members.
#### Papers forwarded to LEWG
* ✅ [P3295R0](https://wg21.link/P3295R0): Freestanding constexpr containers and constexpr exception types - making more previously inaccessible functionality in freestanding accessible in consteval context.
#### Paper reviewed (more work is encouraged)
* ❤️ [P3157R1](https://wg21.link/p3157r1): Generative Extensions for Reflection - set of functionality to manipulate and copy functions to allow writing proxy objects and more. Author was encouraged to work in the direction presented.
We didn’t see “[P2830R4](https://wg21.link/P2830R4): Standardized Constexpr Type Ordering” on request from the author who expects to present it at the next meeting.
*****
### Ranges Study Group (SG9) Progress
*****
SG 9 works on the plan outlined in “[P2760](https://wg21.link/P2760): A Plan for C++26 Ranges“.
#### Papers forwarded to Library Evolution
* [P3137R1](https://wg21.link/P3137R1): views::to_input
#### Papers we gave feedback on
* [P3211R0](https://wg21.link/P3211R0): `views::transform_join`
* [P3216R0](https://wg21.link/P3216R0): `views::slice`
*
They are meant for either reviewing topics relevant to the committee in more depth then possible during the work sessions (such is the case for the Senders/Reveivers (P2300) session) , or for introducing topics which are not procedurally related but are relevant to WG21 (such is the case for “The Beman Project”, which is an initiative by members of WG21 but not as part of their role in WG21).
* 🔎Tuesday: “[P2300R10](https://wg21.link/P2300R10): `std::execution`” (AKA Senders/Receivers) - Deep Dive Introduction. Presented by:
* Dietmar Kaul (an updated first part of his [CppCon 2022 talk](https://www.youtube.com/watch?v=XaNajUp-sGY))
* Lewis Baker (slides for his paper: “[P3143R0](https://wg21.link/p3143r0): An in-depth walk through of the example in P3090R0”))
* 🔎Thursday: [The Beman Project](https://github.com/beman-project/beman?tab=readme-ov-file). Presented by: Jeff Garland.
LEWG will continue to run weekly telecons, we expect to continue the review on”Reflection” and P2300 followup papers, and have the major features already approved by the time we get to the next meeting (Wrocław, Poland).
Tentative policies to be discussed in Poland are: “Explicit Constructors” and “Allocators support”.
Thank you to all our authors and participants, for a great collaboration in a productive and useful review process, and see you (in-person or online) in Wrocław!◝(ᵔᵕᵔ)◜
*****
### Library Evolution Working Group Incubator Study Group (SG18) Progress
*****
#### The following papers require more work / LEWGI review
* [P3045R1](https://wg21.link/P3045R1): Quantities and units library - review is ongoing, will require more time (and possibly dedicated review group) will be seen again by LEWGI.
#### The following papers were forwarded to LEWG
* [P3094R2](https://wg21.link/P3094R2): basic_fixed_string - LEWGI requested the following changes: address fixed capacity, add non-members swap, and support for both const and non const iterators, fix headers section
*****
### Library Working Group (LWG) Progress
*****
LWG met in person throughout the week and reviewed multiple papers.
The main focus for the week was finalizing the wording review for “P2300 `std::execution`” paper so it can be ready for a plenary vote, therefore, most of the LWG sessions were dedicated to it.
#### Papers forwarded to plenary
* [P2968R2](https://wg21.link/P2968R2): Make std::ignore a first-class object - Approved in plenary
* [P2997R1](https://wg21.link/P2997R1): Removing the common reference requirement from the indirectly invocable concepts - Approved in plenary
* [P2389R1](https://wg21.link/P2389R1): dextents Index Type Parameter - Approved in plenary
* [P3168R1](https://wg21.link/P3168R1): Give std::optional Range Support
* [P3217R0](https://wg21.link/P3217R0): Adjoints to "Enabling list-initialization for algorithms": find_last
* [P2985R0](https://wg21.link/P2985R0): A type trait for detecting virtual base classes
* [P0843R12](https://wg21.link/P0843R12): inplace_vector
* [P3235R0](https://wg21.link/P3235R0): std::print more types faster with less memory
* [P2075R5](https://wg21.link/P2075R5): Philox as an extension of the C++ RNG engines
* [P2422R0](https://wg21.link/P2422R0): Remove nodiscard annotations from the standard library specification
And, of course:
* [P2300R10](https://wg21.link/P2300R10): std::execution - Approved in plenary
#### Papers that require more LWG review time
* [P0876R16](https://wg21.link/P0876R16): fiber_context - fibers without scheduler
* [P2019R6](https://wg21.link/P2019R6): Thread attributes
* [P0876R16](https://wg21.link/P0876R16): fiber_context - fibers without scheduler
* [P1450R3](https://wg21.link/P1450R3): Enriching type modification traits
* [P2527R3](https://wg21.link/P2527R3): std::variant_alternative_index and std::tuple_element_index
* [P1928R9](https://wg21.link/P1928R9): std::simd - Merge data-parallel types from the Parallelism TS 2
#### Issues Processing
* [LWG3944](https://wg21.link/LWG3944): Formatters converting sequences of
can be found in “[P3345R0](https://wg21.link/P3345R0): Core Language Working Group "ready" Issues for the June, 2024 meeting”.
#### Papers reviewed and sent to plenary
* [P2963R2](https://wg21.link/p2963r2): Ordering of constraints involving fold expressions - This paper was approved by CWG and subsequently voted in C++26.
* [P3144R2](https://wg21.link/P3144R2): Deleting a Pointer to an Incomplete Type Should be Ill-formed - This paper was approved by CWG and subsequently voted in C++26.
* [P0963R3](https://wg21.link/P0963R3): Structured binding declaration as a condition - This paper was approved by CWG and subsequently voted in C++26.
#### Papers which will need to be seen again by CWG
* [P0562R2](https://wg21.link/p0562r2): Trailing Commas in Base-clauses and Ctor-initializers - Doing review we realized this introduces an ambiguous parse and sent the paper back to EWG.
* [P2686R3](https://wg21.link/p2686r3): Constexpr structured bindings - We reviewed and approved the wording but we are waiting for an implementation before forwarding this paper to plenary.
* [P1061R8](https://wg21.link/p1061r8): Structured Bindings can introduce a Pack - We forwarded this paper to plenary. The paper was subsequently rejected at this time over implementation concerns. We expect it to be seen again once a more complete implementation materializes.
* [P2841R3](https://wg21.link/p2841r3): Concept and variable-template template-parameters - We reviewed this paper and gave guidance feedback. We expect to review this paper again at the next meeting.
* [P2996R4](https://wg21.link/P2996R4): Reflection for C++26 - We started to look at the wording for this major feature and we expect that work to continue over the next few meetings.
*****
# Library Progress
*****
*****
### Library Evolution Working Group (LEWG) Progress
*****
LEWG met during the full week, and reviewed multiple features for C++26.
The main features that captured our time were:
* [P2300R10](https://wg21.link/P2300R10): `std::execution` (forwarded in a previous meeting, LEWG saw related papers)
* [P2996R4](https://wg21.link/P2996R4): Reflection for C++26
“[P2300R10](https://wg21.link/P2300R10): `std::execution`” adding the foundational library concepts for async programming along with an initial set of generic async algorithms.
Additional async programming facilities following this paper are being worked on, and are also targeting C++26; including work on a system execution context/thread-pool, parallel algorithms, concurrent queue supporting both synchronous and async push/pop, and counting_scope which lets you join a set of spawned async operations. The paper was already forwarded to the wording group, LWG, which have been wording on it throughout the week (and voted in plenary by the end of the meeting), but there are still design improvements and fixes papers related to P2300 which LEWG spent time on during the week (and will continue to do so during telecons).
“[P2996R4](https://wg21.link/P2996R4): Reflection for C++26” is under review on LEWG.
It provides the `std::meta` namespace, which contains library functions to support “reflection” functionality, such as traits-equivalent functions and query functions, as well as functions to construct structures based on information from reflected code.
EWG (the language evolution group) approved the language aspect of the proposal, and LEWG (the standard library evolution group) is in the work of reviewing the library aspects of it.
The full list of papers seen by LEWG is below.
#### The following papers forwarded from LEWG (to SGs/LWG)
* ✅ [P3175R2](https://wg21.link/p3175r2): Reconsidering the `std::execution::on` algorithm
* ✅ [P3303R0](https://wg21.link/p3303r0): Fixing Lazy Sender Algorithm Customization
* ✅ [P0843R13](https://wg21.link/p0843r13): `inplace_vector` - plenary approved.
* ✅ [P3235R3](https://wg21.link/p3235r3): `std::print` more types faster with less memory - plenary approved.
* ✅ [P3187R1](https://wg21.link/p3187r1): remove `ensure_started` and
2024-06 St. Louis ISO C++ Committee Trip Report — Fourth C++26 meeting! ⋒
This week was the C++ Committee meeting, in St. Louis, Missouri, USA 🇺🇸, and the work on C++26 is ongoing!
The features voted on will be added gradually to the working draft, and will likely be officially released on the next version (C++26), barring any subsequent changes.
The meeting site was held near the historic [St. Louis Union Station](https://en.wikipedia.org/wiki/St._Louis_Union_Station), providing an opportunity to be exposed to the fascinating history of the city. 🚉
Those who stayed one day past the meeting also had a chance to join the St. Louis Pride Parade. 🌈
The meeting organizers ran the meeting well (as always), and the hybrid (on-site/online) experience worked as expected. We appreciate that greatly!
We plan to keep operating hybrid meetings going forward.
Main C++26 Features approved in St Louis: 🎉
* [P2747R2](https://wg21.link/P2747R2): constexpr placement new
* [P3168R2](https://wg21.link/P3168R2): Give std::optional Range Support
* [P2985R0](https://wg21.link/P2985R0): A type trait for detecting virtual base classes
* [P0843R14](https://wg21.link/P0843R14): inplace_vector
* [P2968R2](https://wg21.link/P2968R2): Make std::ignore a first-class object
* [P2075R6](https://wg21.link/P2075R6): Philox as an extension of the C++ RNG engines
And
* [P2300R10](https://wg21.link/P2300R10): `std::execution`
"P2300: `std::execution`" is a paper suggesting a state-of-the-art async framework, and its approval is big news for our users (more details on this topic are under LEWG’s section).
Thanks to all the authors for the hard work through the years! 👏
*****
# Language Progress
*****
*****
### Evolution Working Group (EWG) Progress
*****
* [P2900R7](https://wg21.link/p2900r7): Contracts for C++ - We spent a day and a half on contracts, and made significant progress towards consensus. There are still points of disagreement, but we have resolved a significant number of them and are hopeful that the next meeting will show yet more increased consensus on the design.
* [P2996R3](https://wg21.link/p2996r3): Reflection for C++26 - moving towards C++26.
* We reviewed 17 core issues and identified authors to write papers to resolve all of them.
#### We saw 39 papers, of which the leading papers were:
#### Forwarded from EWG (to SGs/Core/LEWG) for inclusion in C++26
* ✅ [P2434R1](https://wg21.link/p2434r1): Nondeterministic pointer provenance - promising way to resolve both issues of provenance and pointer zap.
* ✅ [P1494R3](https://wg21.link/p1494r3): Partial program correctness - seen as part of contracts, prevents propagating undefined behavior across boundaries.
* ✅ [P3068R2](https://wg21.link/p3068r2): Allowing exception throwing in constant-evaluation - moving towards C++26.
* ✅ [P0963R2](https://wg21.link/p0963r2): Structured binding declaration as a condition - moving towards C++26 (approved).
* ✅ [P2758R3](https://wg21.link/p2758r3): Emitting messages at compile time - moving towards C++26.
#### The following papers need to be seen again by EWG
* ♽ [P3032R2](https://wg21.link/p3032r2): Less transient constexpr allocation - moving towards C++26. Request implementation experience.
* ♽ [P0876R16](https://wg21.link/p0876r16): fiber_context - fibers without scheduler - track exceptions on a per-fiber basis rather than leaving it implementation-defined. Request implementation experience.
* ♽ [P3096R1](https://wg21.link/p3096r1): Function Parameter Reflection in Reflection for C++26 - encourage further work.
* ♽ [P3310R2](https://wg21.link/p3310r2): Solving partial ordering issues introduced by P0522R0 - received support, but CWG sent back.
* ♽ [P2971R2](https://wg21.link/p2971r2): Implication for C++ - no consensus, but feedback given on how to increase consensus.
* ♽ [P3232R0](https://wg21.link/p3232r0): User-defined erroneous behaviour - encourage further work.
* ♽ [P2719R0](https://wg21.link/p2719r0): Type-aware allocation and deallocation functions - encourage
Cmod - another package manager/module manager for C++ using GitHub
Hey guys. Due to a lack of a good package manager for C++, i have created cmod, which is supposed to be a package manager(rather, module manager) for C++. It is very early alpha, still in the design phase. Here is the github link.
It isn't supposed to be a full build system like cmake, just a simple tool like poetry/pip/npm/maven. If it succeeds, might make it a touch more customizable.
Disclaimer: it probably is shit in its current form. Accepting all forms of criticism, including you telling me it is worthless. It probably is.
Conventions:
-each project has a cmodconfig.json file, specifying source files and dependencies, along with output and build commands.
-each dependency is a module, published on GitHub. The name of the module(and the GitHub project) must be prefixed by your GH name, to ensure uniqueness. Inside each module there must be a namespace, named exactly the same as the module.
-for the packages/libraries/dependencies/modules, the output must be inside of the build folder, the name being the name of the module +".o".
Tested versions:Tested with Macos, GCC 11+, git, Python 3.12 as dependencies.
Also tested with Ubuntu 22.04, GCC 11, git, Python3.10
Example of a module/dependency/package, that has a dependency: https://github.com/AntohiRobert/AntohiRobert\_counter2
If you guys think it's ok, i might refine it a bit, and might make homebrew/ aptitude installers, and other things.
I hope the conventions are ok, a lot of thought went into the design decisions.
https://redd.it/1dw7y5x
@r_cpp
Status of CLion's support of C++20 modules
In my current project I'm experiencing very annoying issue. When I use import statement inside module, and then use something that's from that module whole syntax semantics and IntelliJ sense blows up. Project builds and runs well aside of that.
Those issues are something common and support for C++20 modules isn't quite ready for now?
https://redd.it/1dw4k51
@r_cpp
Who is wrong: gcc or clang?
Hi, folks.
I was experimenting with c++ recently and found an interesting case of clang and gcc behaving differently. Here is the code:
#include <cstddef>
#include <new>
#include <iostream>
using namespace std;
#define NEW_EXTENDED_ALIGNMENT (2 * __STDCPP_DEFAULT_NEW_ALIGNMENT__)
// make it overaligned
struct alignas (NEW_EXTENDED_ALIGNMENT) overaligned
{
static void * operator new (size_t size)
{
std::cout << "operator new\n";
return ::operator new (size);
}
// deliberately deleted
static void * operator new (size_t size, align_val_t alignment) = delete;
};
int main ()
{
auto * o = new overaligned;
}
gcc accepts this code and calls `overaligned::operator new (std::size_t)`, but clang as well as msvc rejects it:
<source>:24:14: error: call to deleted function 'operator new'
24 | auto * o = new overaligned;
| ^
<source>:19:17: note: candidate function has been explicitly deleted
19 | static void * operator new (size_t size, align_val_t alignment) = delete;
| ^
<source>:12:17: note: candidate function not viable: requires single argument 'size', but 2 arguments were provided
12 | static void * operator new (size_t size)
| ^ ~~~~~~~~~~~
1 error generated.
Compiler returned: 1
[Tested](https://godbolt.org/z/hz66boG4h) on latest versions of these compilers.
[Excerpt from the Standard](https://eel.is/c++draft/expr.new#20):
Overload resolution is performed on a function call created by assembling an argument list. The first argument is the amount of space requested, and has type `std::size_t`. If the type of the allocated object has new-extended alignment, the next argument is the type's alignment, and has type `std::align_val_t`. If the new-placement syntax is used, the initializer-clauses in its expression-list are the succeeding arguments. If no matching function is found then
* if the allocated object type has new-extended alignment, the alignment argument is removed from the argument list;
* otherwise, an argument that is the type's alignment and has type `std::align_val_t` is added into the argument list immediately after the first argument;
and then overload resolution is performed again.
I am by no means a seasoned Standard interpreter, but for me it looks like gcc is misbehaving.
What do you think?
https://redd.it/1dy4dr6
@r_cpp
I said a friend can access privates and she blocked me
No wonder C++ is considered one of the most difficult languages to learn out there. I wanted to teach my friend C++ so I used to send random C++ facts to keep her interested in learning more. When I sent her this she blocked me instead.
https://redd.it/1dy0y22
@r_cpp
Firefox breaks "C++" between the two pluses at the end of a line. Bug report + workaround.
From my testing, it seems that Chrome properly prevents line breaks between the two pluses, but Firefox does not, and it irritates me.
I reported it as a bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1906536
You can test it in your browser with the html file I attached to the bug:
https://bug1906536.bmoattachments.org/attachment.cgi?id=9411427
If you wish to fix your web site to display properly with Firefox, you can use something like:
<span style="white-space: nowrap">C++</span>
but it is very annoying to do. I hope Firefox will fix this instead.
https://redd.it/1dxhw8y
@r_cpp
CPP
I just want to say that I love CPP!
https://redd.it/1dxf18k
@r_cpp
How does one link against Windows libc and c++ standard library without relying on one provided by a third party toolchain?
This is probably more of a visual studio topic than a CPP one, but i wasn't really sure where to discuss about it, and of all places this sounded like the most approiate one.
I am writing a clang based tool that among other things at some point it needs to invoke the linker to link some executable. The tools work fine, and i am able to create executables that rely only on windows system libraries and work on different machines.
The issue is that when i invoke the linker, which is a lld i redistribute, unless the machine has installed visual studio indipendenlty from my tools, i cannot assume i will be able to link against the libc or the cpp standard library.
From what i understand the most barebone implementation is in MSVCRT.dll, which is available on all windows machines, but there is no MSVCRT.lib available to link against it.
It would not be a issue in principle to redistribute the MSVCRT.lib provided by visual studio, but that is not in the redistributable folder, and as far as i understand it can only be redistributed when linked to produce a executable or a dll, and since it contains the entry point of the program, i can't wrap it in a dll.
From what i gather this is a problem that every compiler available on windows faces, i have seen mingw and ghci people discussing the issue, and the only solution is to write a custom libc, but that would make malloc incompatible with malloc used by users, if they link against a regular libc too.
Is my understand of the situation correct? Is there really no way to link against even a barebone libc/cpp standard library on windows, unless the user of my tools has some other toolchain implementing the libc installed?
https://redd.it/1dx133a
@r_cpp
Need Suggestion
I am learning C++ from W3School, i understand almost everything whatever i learned from W3 School , but still i am not good at solving problems, I need best resources so i can build problem solving skills so after i can start studying Data structure and algorithms.
Thank you in advance 😊
https://redd.it/1dwuj0b
@r_cpp
auto& f {*(F*)l};
return f(forward<Args>(args)...);
}}};
};
}
}
inline R operator()(Args... args)
{
return ((R(*)(void*, Args...))lambda_handler(nullptr, nullptr).funcs[(int)tag::call])(lambda, forward<Args>(args)...);
}
~sfunc()
{
free_lambda();
}
};
https://redd.it/1dwkgue
@r_cpp
programming language. C++11, C++14, C++17, C++20, C+23, etc.
* TS = Technical Specification. "Feature branches" available on some but not all implementations. Coroutines TS v1, Modules TS v1, etc.
* CD = Committee Draft. A draft of an IS/TS that is sent out to national standards bodies for review and feedback ("beta testing").
**Updates since the last Reddit trip report are in bold.**
Feature | Status | Depends On | Current Target (Conservative Estimate) | Current Target (Optimistic Estimate)
-|-|-|-|-
[Senders](https://wg21.link/P2300) | Plenary approved | | C++26 | C++26
[Networking](https://wg21.link/P2171) | Require rebase on Senders | Senders | C++29 | C++26
[Linear Algebra](https://wg21.link/P1673) | Plenary approved | | C++26 | C++26
[SIMD](https://wg21.link/P1928) | Forwarded to LWG | | C++26 | C++26
[Contracts](https://wg21.link/P0542) | Processed on Study Group SG21 | | C++29 | C++26
[Reflection](https://wg21.link/P2996R0) | Forwarded to CWG, Design review in LEWG | | C++26 | C++26
[Pattern Matching](https://wg21.link/P1371) | No developments | | C++29 | C++29
[**Last Meeting's Reddit Trip Report.**](https://www.reddit.com/r/cpp/comments/1bloatw/202403_tokyo_iso_c_committee_trip_report_third/)
**If you have any questions, ask them in this thread!**
**Report issues by replying to the top-level stickied comment for issue reporting.**
*/u/InbalL, Library Evolution (LEWG) Chair, Israeli National Body Chair*
*/u/jfbastien, Evolution (EWG) Chair*
*/u/hanickadot, Compile-Time programming (SG7) Chair, Evolution (EWG) Vice Chair, Czech National Body Chair*
*/u/lewissbaker, Main P2300 (std::execution) author*
*/u/ben_craig, Library Evolution (LEWG) Vice Chair*
*/u/c0r3ntin, Library Evolution (LEWG) Vice Chair*
*/u/foonathan, Ranges (SG9) Vice Chair*
*/u/V_i_r, Numerics (SG6) Chair*
*/u/bigcheesegs, Tooling (SG15) Chair*
*/u/tahonermann, Unicode (SG16) Chair*
*/u/mtaf07, Contracts (SG21) Chair*
*/u/timur_audio, Contracts (SG21) Vice Chair*
*/u/je4d, Networking (SG4) Chair*
*... and others ...*
https://redd.it/1dwc7f2
@r_cpp
[P3230R0](https://wg21.link/P3230R0): `views::(take|drop)_exactly`
All add new useful views to the standard library.
We also approved the design of “[P2848R0](https://wg21.link/P2848R0): `std::is_uniqued`”, a small paper that adds a missing algorithm, and look forward to the naming discussion in library evolution.
We also held a joint session with SG1 concurrency to discuss parallel algorithms.
*****
### Low Latency Study Group (SG14) Progress
*****
SG14 did not meet during the St. Louis meeting. We continue to hold monthly telecons to discuss low latency and embedded related papers.
*****
### Tooling Study Group (SG15) Progress
*****
The main focus of SG15 these days is reviewing a paper for creating a new Ecosystem IS (tentative, might be a TR), which will be developed parallelly to the C++ Standard.
* ✅ [P2656R2](https://wg21.link/P2656R2): C++ Ecosystem International Standard -
We're planning on a new international standard dedicated to tooling concerns called the Ecosystem IS. Forwarded to the evolution groups.
We also saw additional 3 papers, and forwarded 2 of them for the Ecosystem IS.
#### Papers reviewed
* 👍 [P3267R1](https://wg21.link/p3267R1): C++ contracts implementation strategies - We discussed various implementation strategies for contracts with a few Itanium C++ ABI people, and a contracts implementer in the room. We had no tooling-related concerns with contracts, but believe that the best ABI would require linker changes to get the best performance.
#### Papers targeting the Ecosystem IS
* ✅ [P3051R1](https://wg21.link/P3051R1): Structured Response Files - Provides a portable response file format, and a structured option format. Forwarded to the evolution groups along with the initial Ecosystem IS.
* ❤️ [P3286R0](https://wg21.link/P3286R0): Module Metadata Format for Distribution with Pre-Built Libraries - Provides a way to find and parse module interface files from 3rd party libraries. We liked it and encouraged further work targeting the Ecosystem IS.
*****
### Text and Unicode Study Group (SG16) Progress
*****
SG16 did not meet in person this week as it is too hard to assemble a quorum when competing with all of the other SGs and WGS. However, SG16 did participate in two joint sessions with LEWG to discuss the following papers:
* [P2996R4](https://wg21.link/P2996R4): Reflection for C++26 - we discussed the string_view returning functions`name_of`(ment to return name which can be used to construct language utils) `qualified_name_of` (as named) and `display_name_of`(targeting logging utils, promised to always return a string). We still need to discuss the “u8” versions of these.
* [P2626R0](https://wg21.link/P2626R0): charN_t incremental adoption: Casting pointers of UTF character types - LEWG gave indication that they would like this problem to be solved, by doing so starting the motion of Core making sure the specification enabling the solution.
SG16 will continue to meet approximately twice a month. We have plenty of work in front of us and that won’t change anytime soon! Upcoming topics will focus on adding some limited support for char8_t, char16_t, and char32_t to std::format() and friends ([P3258R0](https://wg21.link/P3258R0)), resolving questions of encoding with regard to the reflections proposal ([P2996R4](https://wg21.link/P2996R4)), the quantities and units proposal ([P3045R1](https://wg21.link/P3045R1)), the exceptions in constant evaluation proposal ([P3068R2](https://wg21.link/P3068R2)), and in various LWG issues.
*****
### Contracts Study Group (SG21) Progress
*****
SG21 met for two days (Wednesday & Thursday) in St. Louis and made great progress with “[P2900R7](https://wg21.link/P2900R7): Contracts for C++” (the Contracts MVP proposal). The proposal still appears to be on track for C++26.
During SG21 meeting, we reviewed:
* Discussing the results from EWG's review of P2900, which happened on Monday & Tuesday, and in which we successfully resolved many contentious design issues.
* We
char to sequences of wchar_t
* [LWG3918](https://wg21.link/LWG3918): std::uninitialized_move/_n and guaranteed copy elision
* [LWG3971](https://wg21.link/LWG3971): Join ranges of rvalue references with ranges of prvalues
* [LWG2829](https://wg21.link/LWG2829): LWG 2740 leaves behind vacuous words
* [LWG2833](https://wg21.link/LWG2833): Library needs to specify what it means when it declares a function constexpr
Note: Issues finalized during a meeting are tentatively ready but voted on during the next meeting (in this case, Poland).
*****
# Study Group Progress
*****
*****
### Concurrency and Parallelism Study Group (SG1) Progress
*****
SG1 saw several papers proposing additional facilities and fixes for `std::atomic[_ref]`, several papers looking to address outstanding pointer provenance issues and several papers relating to additional `std::execution` facilities, such as parallel-algorithms, system-context and concurrent-queues.
#### The following papers were forwarded to LEWG:
* [P3323R0](https://wg21.link/P3323R0): cv-qualified types in atomic and atomic_ref - clarifies that a `std::atomic` of cv-qualified types is ill-formed, and also fixes a bug in the specification that will allow `std::atomic_ref` of cv-qualified types.
* [P3255R0](https://wg21.link/P3255R0): Expose whether atomic notifying operations are lock-free - was forwarded with modifications to also allow querying whether wait operations are signal-safe.
* [P3309R0](https://wg21.link/P3309R0): constexpr atomic and atomic_ref
* [P3248R1](https://wg21.link/PR3248R1): Require xintptr_t
* [P3138R1](https://wg21.link/P3138R1): views::cache_last
* [P3187R1](https://wg21.link/P3187R1): remove ensure_started and start_detached from P2300 - accepted and merged into P2300R10.
* [p3149r4](https://wg21.link/P3149R4): async_scope - we reviewed the changes to the design and a
question about custom allocator support.
#### The following papers will be seen again by SG1:
* [P3111R0](https://wg21.link/P3111R0): Atomic Reduction Operations - proposes adding new operations when the result is not required (e.g. `add()` instead of `fetch_add()`) and was design-approved.
* [P3306R0](https://wg21.link/P3306R0): Atomic Read-Modify-Write improvements - proposes additional atomic operations for numeric types, including shift-left, shift-right, multiply, divide, and modulus, was given encouragement to come back with wording.
* [P3330R0](https://wg21.link/P3330R0): User-defined atomic Read-Modify-Write operations - proposes additional atomic which make it easier to apply user-defined transformations to atomic values, which would normally require writing CAS-loops. This paper was discussed and requires additional work.
* [P3179R2](https://wg21.link/P3179R2): C++ parallel range algorithms - proposes adding overloads of the C++17 parallel algorithms that take ranges and range-compositions instead of iterators.
SG1 saw papers discussing the memory model and pointer provenance and made progress on some promising directions for resolving the outstanding issues:
* [P2414R3](https://wg21.link/P2414R3): Pointer lifetime-end zap proposed solutions
* [P3292R0](https://wg21.link/P3292R0): Provenance and Concurrency
* [P2434R1](https://wg21.link/P2434R1): Nondeterministic pointer provenance
* [P3064R1](https://wg21.link/P3064R1): How to avoid OOTA without really trying
* [P3181R0](https://wg21.link/P3181R0): Atomic stores and object lifetime
SG1 also saw several papers proposing facilities that build on the async `std::execution` added by P2300:
* [P2079R4](https://wg21.link/P2079R4): System execution context - proposes adding facilities that provide
portable access to a system thread-pool, such as libdispatch, Windows Thread Pool or TBB. We discussed
several aspects of this proposal relating to replaceability, lifetime and ABI.
* [P0260R10](https://wg21.link/P2060R10): C++ Concurrent Queues - proposes some concepts for synchronous and
asynchronous concurrent queues along with a `bounded_queue` type. This paper was design-approved and
`start_detached` from P2300
* ☑️[P3309R0](https://wg21.link/p3309r0): constexpr atomic and atomic_ref - require input from SG22 and approval by electronic poll.
* ☑️[P3323R0](https://wg21.link/P3323R0): cv-qualified types in atomic and atomic_ref - require approval by electronic poll.
* ☑️[P2897R1](https://wg21.link/P2897R1): aligned_accessor: An mdspan accessor expressing pointer overalignment - require approval by electronic poll.
* ☑️[P3008R2](https://wg21.link/P3008R2): Atomic floating-point min/max - require approval by electronic poll.
###### The following paper was not sent to LWG but merged into the Parallelism TS 2:
* ✅[P1928R10](https://wg21.link/p1928r10): Merge data-parallel types from the Parallelism TS 2 - Merged into TS
* ✅[P3287R0](https://wg21.link/p3287r0): Exploration of namespaces for std::simd
#### The following papers need to be seen again by LEWG
* 🔁 [P3164R1](https://wg21.link/p3164r1): Improving diagnostics for sender expressions
* 🔁 [P1030R6](https://wg21.link/p1030r6): std::filesystem::path_view
* 🔁 [P3275R0](https://wg21.link/p3275r0): Replace simd operator[] with getter and setter functions - or not
* 🔁 [P2769R2](https://wg21.link/p2769r2): get_element customization point object
* 🔁 [P2626R0](https://wg21.link/p2626r0): charN_t incremental adoption: Casting pointers of UTF character types - got encouragement to solve the issue, language changes will need to be applied by Core before we can see it back.
* 🔁 [P3149R5](https://wg21.link/p3149r5): async_scope -- Creating scopes for non-sequential concurrency - design made progress, wording required.
* 🔁 [P2996R4](https://wg21.link/P2996R4): Reflection for C++26 - we reviewed:
* Wording that indicates no guarantees between different versions of the standard in regards to reflected code, and in particular, no guarantees for the standard library reflected implementation details.
* Three name-returning functions (“name_of”, “qualified_name_of”, “display_name_of”) in a joint session with SG16 (the u8 versions are waiting for SG16’s input and will be reviewed by LEWG).
* We approved 10 trait-like functions: “is_virtual”, “is_pure_virtual”, “is_override”, “is_deleted”, “is_defaulted”, “is_explict”, “is_bit_field”, “is_const”, and “is_volatile”, and “is_noexcept”.
* We gave feedback on the design of bit_offset functions (final design is to be approved by LEWG).
* We will be continuing the review on P2996 during telecons.
* 🔁 [P3068R2](https://wg21.link/p3164r1): Allowing exception throwing in constant-evaluation
* 🔁 [P0260R10](https://wg21.link/P0260R10): C++ Concurrent Queues - got a lot of design feedback, and will be seen again after that feedback is applied.
* 🔁 [P3325R0](https://wg21.link/P3325R0): A Utility for Creating Execution Environments - design approved, wording review is required.
* 🔁 [P2746R5](https://wg21.link/P2746R5): Deprecate and Replace Fenv Rounding Modes
* 🔁 [P3299R0](https://wg21.link/P3299R0): Range constructors for std::simd - got design feedback, will be seen by LEWG again.
#### The following papers had no consensus
* 🚫 [P2413R1](https://wg21.link/P2413R1): Remove unsafe conversions of unique_ptr
* 🚫 [P2921R0](https://wg21.link/P2921R0): Exploring std::expected based API alternatives for buffer_queue
#### Policies discussion
Policies were created to guide authors of standard library proposals, and by doing so, improve the process and save both the group and the authors’ time.
Information about policies can be found in: “[P2267R1](https://wg21.link/p2267r1): Library Evolution Policies (The rationale and process of setting a policy for the Standard Library)”.
* ✅ [P2422R1](https://wg21.link/p2422r1): Remove `nodiscard` annotations from the standard library specification (plenary approved)
* 🔁 [P3116R0](https://wg21.link/p3116r1): Policy for explicit (should be seen again by LEWG)
#### Evening Sessions
We had two evening sessions during the week (initiated by our members).
Evening sessions are informative sessions, during which we do not take any binding votes.
further work.
* ♽ [P3140R0](https://wg21.link/p3140r0): std::int_least128_t - encourage further work.
* ♽ [P2822R1](https://wg21.link/p2822r1): Providing user control of associated entities of class types - weak consensus, feedback provided.
* ♽ [P2989R1](https://wg21.link/p2989r1): A Simple Approach to Universal Template Parameters - encourage further work.
* ♽ [P3074R3](https://wg21.link/p3074r3): trivial union (was std::uninitialized) - encourage further work.
* ♽ [P2786R6](https://wg21.link/p2786r6) - Trivial Relocatability For C++26 - sent back from CWG to EWG, feedback was given, and volunteers identified to resolve open issues.
* ♽ [P3097R0](https://wg21.link/p3097r0): Contracts for C++: Support for Virtual Functions - encourage further work.
* ♽ [P2825R2](https://wg21.link/p2825r2): Overload Resolution hook: declcall(unevaluated-postfix-expression) - encourage further work.
* ♽ [P3177R0](https://wg21.link/p3177r0): const prvalues in the conditional operator - encourage further work.
#### The following papers had no consensus
* 🚫 [P3253R0](https://wg21.link/p3253r0): Distinguishing between member and free coroutines - no consensus.
* 🚫 [P3254](https://wg21.link/p3254r0)R0 --- [Reserve identifiers preceded by @ for non-ignorable annotation tokens](https://github.com/cplusplus/papers/issues/1914): no consensus.
* 🚫 [P2992R1](https://wg21.link/p2992r1): Attribute [[discard("reason")]]] - no consensus (Needs more work).
* 🚫 [P3087R0](https://wg21.link/p3087r0): Make direct-initialization for enumeration types at least as permissive as direct-list-initialization - no consensus.
* 🚫 [P1112R5](https://wg21.link/p1112r5): Language support for class layout control - no consensus for this specific paper, but consensus was previously expressed to resolve the issue.
As a rule, papers with no consensus can be seen again if new information comes up.
#### Summary
* We ran out of time to see 4 papers.
* 5 papers were without presenter.
* 3 papers were deferred at the request of the author.
*****
### Evolution Working Group Incubator Study Group (SG17) Progress
*****
On Thursday we didn’t have a quorum so we met only on Friday with half time allocated than expected. We still got to see 6 out of 10 scheduled papers:
#### The following papers require more work / EWGI review
* ♽ [P3245R0](https://wg21.link/p3245r0): Allow nodiscard in type alias declaration - Ability to create copy of types or give a type alias different properties. We gave author feedback on prefered design.
* ♽ [P3312R0](https://wg21.link/p3312R0): Overload Set Types - Ability to pass an overload set identified by name as callable. We gave the author feedback on design.
* ❤️ [P3166R0](https://wg21.link/p3166r0): Static Exception Specifications - Exception mechanism design which doesn’t need any allocation and can be used deterministically and safely used in environments which currently doesn’t support exceptions. We gave encouragement to the author to continue work on the proposed design.
#### The following papers were forwarded to EWG
* ✅ [P3298R0](https://wg21.link/p3298r0): Implicit user-defined conversion functions as operator.() - Mechanism to allow writing proxy types and smart references.
* ✅ [P2952R1](https://wg21.link/p2952r1): auto & operator=(X&&) = default - Ability to make operator= user defaulted.
* ✅ [P3176R0](https://wg21.link/p3176r0): The Oxford variadic comma - Deprecating va_arg after a variadic arguments `auto......`.
We didn’t see papers: “[P3093R0](https://wg21.link/p3093r0): Attributes on expressions”, “[P3218R0](https://wg21.link/p3218r0): const references to constexpr variables”, “[P3259R0](https://wg21.link/p3259r0): const by default”, and “[P3266R0](https://wg21.link/p3266r0): non referencable types”. We plan to have a telecon soon to see these papers.
*****
### Core Working Group (CWG) Progress
*****
CWG met during the full week, and reviewed multiple features for C++26, along with many issues that were either prioritized or resolved.
The full list of issues resolved in this meeting
Can linking be parallelized?
Like the title says - I know we can build multiple translation units at the same time, but can linking also be done in parallel?
https://redd.it/1dw5t9f
@r_cpp
Compile-time JSON deserialization in C++
abdulgh/compile-time-json-deserialization-in-c-1e3d41a73628" rel="nofollow">https://medium.com/@abdulgh/compile-time-json-deserialization-in-c-1e3d41a73628
https://redd.it/1dw61lr
@r_cpp
Refined Input, Degraded Output: The Counterintuitive World of Compiler Behavior
https://dl.acm.org/doi/10.1145/3656404
https://redd.it/1dw3kkw
@r_cpp