The result of the C++26 DIS ballot

C++ is probably the largest, most complex programming language to ever exist. I, as a former C++ compiler developer, find it hard to keep up with the language changes. What chance does an average user have?

Oh my, here I'm looking like a fool, literally gave a talk on the new <meta>/Reflection feature on Thursday and doing it assumed that it was more or less a lock (Well I guess the refl feature will come out if contracts can be dumped and the standard gets out even if it won't technically be in C++26 anymore :P ) The reflection feature is good, I would've settled for less but there's some pretty cool stuff enabled by it. - direct to struct JSON parsing with property-name aliasing via annotations - field creation/renaming, I've made a make_named<"a","b">(1,"hello") to create an object with fields named a and b (think of std::make_tuple on steroids) - I'm basically halfway done with a DB abstraction that can be used similarly to C#'s Linq. struct [[=sql26::name("posts")]] post { int id; std::string name; }; dbcontext<post> dbctx; for(auto post:dbctx.posts.where([](auto post) { return post.id>100; }) { ... } ^- in the above example the template inclusion of post creates the posts-field in the context, the where predicate lambda gets a decorated variant of the post type members that are then deferred until execution (starting iterating the itererable). It's dangerously powerful though since all of this is enabled by consteval, so any IDE support will need to be running the consteval code continiously in these scenarios to update type-info before being able to do code completion (even if people are probably way into LLM's to bother anymore?). The talk isn't online yet since they haven't had time to edit the videos. The JSON and make_named example/code can be found in my repo, haven't pushed the SQL feature yet as I'm not happy with some other parts of the API surface yet (aggregation is hard to express/translate compactly and unambigiously). https://github.com/whizzter/ret26

I can only describe current C++ as a Frankenstein. Trying to introduce modern features while having to keep compatibility is just really hard and probably not "the right way".

This contracts design is good, opposed to Gudstedt's variant with the semicolon. Because here it is trivial to make them backwards compatible, by just using a PRE() and POST() macro which are empty pre-C++26. The contracts_assert is either static or runtime, which the compiler can decide. Better than explicit static/asserts, which are either unnecessary or costly.

Went looking on reddit and other places for a good, non-political explanation of what's going on. Didn't find that, but I did find this good critique of contracts by david_chisnall: https://lobste.rs/s/rlrfew/balloting_has_completed_for_c_26#...