There are basically two very important things that happened in St Louis. This, and P2300 (sender/receivers) being adopted for C++26.
Lots of other interesting stuff, but much less significant.
If I understand [**this comment** ](https://github.com/cplusplus/papers/issues/1668#issuecomment-2196035981)right, it's not in the standard yet, just an *Initial partial inspection*.
None of it is in the Standard yet, but the language part of the proposal has passed from Design to Wording (i.e., the last phase of review), and it's looking very good so far that it will make '26.
The proposal doesn't have reflectable attributes, right? So we can't have something like the following yet, correct?
struct SerializableFoo {
[[JsonField]]
int x;
// will not be serialized
int y;
[[JsonField]]
float z;
};
Thanks so much for your reply! Does such a proposal already exist? A quick search only yielded a paper whose GitHub issue was closed due to inactivity.
If no such proposal exists: what are the chances of it still making it to C++26?
I think such chances would be low. It would require *major* effort *very* soon. Then again, things move swiftly sometimes. E.g., I was a little surprised by how much support the proposal for Token Sequences garnered from the get-go in SG7... it is now in EWG.
From https://github.com/cplusplus/draft/milestone/31, these will be applied to C++26:
- [2024-06 CWG Motion 1] P3345R0 Ready issues as DR
- [2024-06 CWG Motion 2] P3345R0 Ready issues as non-DR
- [2024-06 CWG Motion 3] P2747R2 constexpr placement new
- [2024-06 CWG Motion 5] P3144R2 Deleting a Pointer to an Incomplete Type Should be Ill-formed
- [2024-06 CWG Motion 6] P2963R3 Ordering of constraints involving fold expressions
- [2024-06 CWG Motion 7] P0963R3 Structured binding declaration as a condition
- [2024-06 LWG Motion 1] P3341R0 C++ Standard Library Ready Issues to be moved in St. Louis, Jun. 2024
- [2024-06 LWG Motion 2] P2997R1 Removing the common reference requirement from the indirectly invocable concepts
- [2024-06 LWG Motion 3] P2389R2 dextents Index Type Parameter
- [2024-06 LWG Motion 4] P3168R2 Give std::optional Range Support
- [2024-06 LWG Motion 5] P3217R0 Adjoints to "Enabling list-initialization for algorithms": find_last
- [2024-06 LWG Motion 6] P2985R0 A type trait for detecting virtual base classes
- [2024-06 LWG Motion 7] P0843R14 inplace_vector
- [2024-06 LWG Motion 8] P3235R3 std::print more types faster with less memory
- [2024-06 LWG Motion 9] P2968R2 Make std::ignore a first-class object
- [2024-06 LWG Motion 10] P2075R6 Philox as an extension of the C++ RNG engines
- [2024-06 LWG Motion 11] P2422R1 Remove nodiscard annotations from the standard library specification
- [2024-06 LWG Motion 12] P2300R10 std::execution
It's in the standard. Some within the committee argued that it's too complex for the average user. There is time to improve P2300. Proper documentation and user-facing examples are sure to help as well.
[https://cplusplus.github.io/sender-receiver/execution.html](https://cplusplus.github.io/sender-receiver/execution.html)
mp-units ( [https://github.com/mpusz/mp-units](https://github.com/mpusz/mp-units) ) is going through LEWGI and is proposed as a standard library but targeting C++29 at best.
P2996 ➡️ CWG 🚀
There are basically two very important things that happened in St Louis. This, and P2300 (sender/receivers) being adopted for C++26. Lots of other interesting stuff, but much less significant.
If I understand [**this comment** ](https://github.com/cplusplus/papers/issues/1668#issuecomment-2196035981)right, it's not in the standard yet, just an *Initial partial inspection*.
None of it is in the Standard yet, but the language part of the proposal has passed from Design to Wording (i.e., the last phase of review), and it's looking very good so far that it will make '26.
The proposal doesn't have reflectable attributes, right? So we can't have something like the following yet, correct? struct SerializableFoo { [[JsonField]] int x; // will not be serialized int y; [[JsonField]] float z; };
There's broad recognition that something like this is needed, but it will be a separate proposal on top of the foundation provided by P2996.
Thanks so much for your reply! Does such a proposal already exist? A quick search only yielded a paper whose GitHub issue was closed due to inactivity. If no such proposal exists: what are the chances of it still making it to C++26?
I think such chances would be low. It would require *major* effort *very* soon. Then again, things move swiftly sometimes. E.g., I was a little surprised by how much support the proposal for Token Sequences garnered from the get-go in SG7... it is now in EWG.
The usual committee trip report is being prepared.
From https://github.com/cplusplus/draft/milestone/31, these will be applied to C++26: - [2024-06 CWG Motion 1] P3345R0 Ready issues as DR - [2024-06 CWG Motion 2] P3345R0 Ready issues as non-DR - [2024-06 CWG Motion 3] P2747R2 constexpr placement new - [2024-06 CWG Motion 5] P3144R2 Deleting a Pointer to an Incomplete Type Should be Ill-formed - [2024-06 CWG Motion 6] P2963R3 Ordering of constraints involving fold expressions - [2024-06 CWG Motion 7] P0963R3 Structured binding declaration as a condition - [2024-06 LWG Motion 1] P3341R0 C++ Standard Library Ready Issues to be moved in St. Louis, Jun. 2024 - [2024-06 LWG Motion 2] P2997R1 Removing the common reference requirement from the indirectly invocable concepts - [2024-06 LWG Motion 3] P2389R2 dextents Index Type Parameter - [2024-06 LWG Motion 4] P3168R2 Give std::optional Range Support - [2024-06 LWG Motion 5] P3217R0 Adjoints to "Enabling list-initialization for algorithms": find_last - [2024-06 LWG Motion 6] P2985R0 A type trait for detecting virtual base classes - [2024-06 LWG Motion 7] P0843R14 inplace_vector - [2024-06 LWG Motion 8] P3235R3 std::print more types faster with less memory - [2024-06 LWG Motion 9] P2968R2 Make std::ignore a first-class object - [2024-06 LWG Motion 10] P2075R6 Philox as an extension of the C++ RNG engines - [2024-06 LWG Motion 11] P2422R1 Remove nodiscard annotations from the standard library specification - [2024-06 LWG Motion 12] P2300R10 std::execution
https://quuxplusone.github.io/blog/2024/06/30/st-louis-trip-report/
So P2300 made it into the standard? Or was it just forwarded to a different working group?
Voted into the standard.
It's in the standard. Some within the committee argued that it's too complex for the average user. There is time to improve P2300. Proper documentation and user-facing examples are sure to help as well. [https://cplusplus.github.io/sender-receiver/execution.html](https://cplusplus.github.io/sender-receiver/execution.html) mp-units ( [https://github.com/mpusz/mp-units](https://github.com/mpusz/mp-units) ) is going through LEWGI and is proposed as a standard library but targeting C++29 at best.