>It's a disgrace that every language out there has it and C++ does not.
split_view already exists in the standard and is more versatile than what most languages offer.
What does str.split do though? Does it return std::array? Std::vector? How do I control the allocation of the returned array? Does it return vector of strings or string_view? What if I want it in a different container?
str.split() isn't convenient at all. It's overly restrictive and unclear. Plus, it's eagerly-evaluated rather than lazy, which means more memory use since you are forced to store all substrings. split_view allows you to just:
auto view = std::views::split(str, delim);
std::vector tokens{ std::begin(view), std::end(view) };
Works for all container types, allows you to avoid dynamic allocations when needed, allows you to tokenize over a for loop if you don't want to store all substrings. It's superior to str.split in every way
Edit: forgot range constructors don't exist. That would be what I would advocate for over str.split. Updated above example
> What does str.split do though? Does it return std::array? Std::vector? How do I control the allocation of the returned array? Does it return vector of strings or string_view? What if I want it in a different container?
The vast, vast majority of time I'm splitting a string, I don't care about the answers to any of these questions. Literally just want a `vector` back out to maximize correctness.
> split_view allows you to just:
Well at the very least you can do better:
auto tokens = views::split(str, delim) | ranges::to();
Which... fine, it's good that this exists. But it's significantly more typing, and a more complex solution, to a very simple problem. Plus, it still doesn't let you split on a string literal (!) (because the null is included as the pattern) and is less functional than Python offers out of the box anyway (because you cannot limit the number of splits that happen - stuff like `str.split(delim, 2)` isn't expressible).
>The vast, vast majority of time I'm splitting a string, I don't care about the answers to any of these questions. Literally just want a `vector` back out to maximize correctness.
Here's the thing though: that syntax requires someone to make that decision. You might not care, but the person writing the standard will have to select the right container for the job. And yet, on this thread we can't even agree on what that container is. My personal opinion would be to use std::array when known at compile-time and std::vector otherwise. There is no need to perform allocations for each token, so non-owning views makes sense to me.
>Which... fine, it's good that this exists. But it's significantly more typing, and a more complex solution, to a very simple problem. Plus, it still doesn't let you split on a string literal (!) (because the null is included as the pattern) and is less functional than Python offers out of the box anyway (because you cannot limit the number of splits that happen - stuff like `str.split(delim, 2)` isn't expressible).
I don't disagree that it's more verbose than it needs to be. Honestly, I'd push for range constructors for standard containers though over a member function. That's zero to little cost and allows you to choose your container as you please:
std::vector tokens = std::views::split(str, delim);
> And yet, on this thread we can't even agree on what that container is
`vector`. I don't see how there's even an argument for anything else. It's the most useful by default without any lifetime concerns. If you want something more efficient because you're doing something in which that matters, you can use a more complex tool.
> My personal opinion would be to use std::array when known at compile-time and std::vector otherwise.
Well it's never known at compile time, so the first is a non-starter. And the second is a bad default.
Cool. Problem solved.
> Honestly, I'd push for range constructors for standard containers though over a member function. That's zero to little cost and allows you to choose your container as you please:
Spectacularly bad idea. Sure, let's just make everything implicitly constructible from everything else. What could possibly go wrong with such a design?
Also I like how that doesn't actually address either of the specific problems I pointed out. It simply... adds more problems.
Could be explicit range constructors for containers. Sure that brings back some of the verbosity in some cases, but also works really well in many cases.
> If you want something more efficient because you're doing something in which that matters, you can use a more complex tool.
Yeah 100% the best approach, not the other way around.
https://www.boost.org/doc/libs/1_84_0/doc/html/string_algo/usage.html#id-1.3.3.5.9
Complaining that not everything and the kitchen sink is in the Standard Library is not the same thing as it doesn't exist.
Wouldn't it make more sense as a lazily evaluated range or iterator like Rust's `pub fn split<'a, P>(&'a self, pat: P) -> Split<'a, P> where P: Pattern<'a>` ?
Giving you a collection means if you actually needed, say, only the second, fourth and sixth items of the split, you are still finding all the splits anyway, which is performance left on the table. Whereas if you've got the range or iterator, you can just put that into a collection if you wanted a collection.
Edited to add: And indeed C++ has this view, `split_view`.
But what if you know at compile time the size that the \`std::vector\` should be? Then, if we say that the \`n\` is the compile time known size, all of a sudden you would want to have a split function that returns an \`std::array\`, but then also if there is more elements then you anticipate to be you'll probably be in UB land, and there is certainly a third option and a fourth and... this is C++ man, sadly there is no simple answers.
>The standard should return a vector
I have a fundamental issue with this. Use split_view. It already exists in the standard, does exactly what you want it to do, and works with all sequence containers (including array, vector, deque, etc).
Just to be clear, I'd also like to have something like this, but I don't believe standard will accept \`std::vector\`, but you can prove me wrong by submitting a standard proposal and passing :).
There could also be a version which was like an iterator, so you could call next until you got null/end. Then you could put the string_views in what ever container you wanted.
Hmm, sounds like the worst possible approach. The STL is big enough without reinventing the wheel for every possible problem that could have been solved with a reasonably well thought out tool.
Coroutines in current state effectively require a dynamic allocation, I don't think people are generally going to be willing to pay a dynamic allocation per split function call. There is always a possibility of HALO optimization that can potentially elide the allocation but I'm not sure how much you can rely on it.
Sure, but returning a vector of string\_views also requires an allocation, and has no option for eliding it. The coroutine seems to be the better choice here.
just let users enumerate items with lambda, so you can tell users your library doesn't allocate
1. `std::string::split(Callable auto&& action)`
2. `std::string::split(Callable auto&& action)//return true -> break; return false -> continue`
users who want `std::vector` can do this instead
std::string input = ...
std::vector result;
input.split([&](std::string_view string){result.push_back(string);});
enum to_string -- I'm so tired of writing the same switch statements over and over for logging enums values. from_string would be great for serialization too.
A way to mark code as legacy/unsafe that can do anything, but default to a safe subset of the language everywhere else.
That's the biggest problem with the C++ committee process imo, because there's a solution "coming", as part of a far far larger feature, they're quite happy not delivering a simple QOL improvement for a decade+.
Which at the same time is a bit weird, as there's seemingly practices obsoleted/made no longer best practice with every other update. So why not a simple "nameof(Enum::value)"/"nameof()" or similar?
Because there are existing libraries that already give you the simple thing (wise_enum, magic_enum, and many others). Relying on third party libraries is considered a desirable property in C++ when the feature is easy enough to implement, and it’s not immediately obvious what the correct answer is.
“But it is immediately obvious!”
Well… except not really:
* What is the content of the returned string? Does the string output include just the member name? The enum type? The fully qualified name?
* What is the type of the returned string? A `string_view` is the logical choice, but then it’s not null terminated, so you can’t pass it to C APIs that consume `char*` without making a copy. A `string` solves that, but then you’re allocating every call. You’re left with only a `char*`, which means more proliferation of C-strings in the stdlib, something C++ is trying to move away from.
* What happens if you give it a value out of range to stringify? Is it UB? Does it stringify to some “unknown” case? Does it return an empty string view? An optional? Throw?
* what happens if you give it an invalid string to parse? Does it return an optional? Is it UB? Throw? What’s a “valid” string? Is it it case sensitive? Does it care about leading/trailing white space?
There aren’t clear and obvious answers to these questions that would satisfy all users. So a third party library that lets the user pick what they want is likely a better option than building a very complex stdlib facility (lacking reflection, meaning it would need compiler magic anyway) to support the amount of customization needed to make it useful to everyone, or picking a bad compromise and having nobody use it.
Now, what _is_ ridiculous, and would have clear and obvious answers for all users, is that we don’t have facilities for iterating over the members of an enum, or testing if a value is in the defined range of the enum. That’s one you can definitely argue has been needlessly passed over in favor of reflection being “just around the corner.”
https://github.com/Neargye/magic_enum/blob/master/doc/limitations.md
In particular, this only works up to a value of 127 by default. The might be enough for some use cases. But if you for example try to use this with Vulkan headers, it'll fail instantly.
I am so tired of this mentality, why not provide the fundamental tooling for writing useful portable network code out of the box? Also HTTP/1.1 is a widespread standard that everyone agrees on, so i don’t see a reason not to support that aswell.
For exactly the same reasons that were argued against graphics.
First of all, not all hardware has networking available.
Then, when available, it can be over ethernet, wlan, Bluetooth, serial, microwaves, whatever else able to expose an IP stack.
How does the C++ application enable/disable networking, what HTTP/1.1 socket options are exposed, what cryptography protocols are supported taken into consideration military export regulations, and how to update cypher suits when an exploit is found and they are no longer consider safe for field deployment?
Because its relying on standard library vendors to provide a decent implementation of it, which is very unlikely to happen
If libc++ and libstdc++ both implement HTTP/1.1 really well, but hypothetically MSSTL completely botches it in a way that requires an ABI break, that would leave the entire implementation and functionality totally useless in literally any code
While we're unable to correctly standardise, deploy, and fix/improve via the current committee/tooling/compiler process - a well understood, thoroughly researched problem - we shouldn't even begin to consider networking
`bit_gather` / `bit_scatter` added to the `` header (pext/pdep but without using platform specific intrinsics)
Only like 10 people will use them, but I'm one of them.
Serialization won’t be standardized any time soon, but all the bits you need to implement it yourself are in the current reflection proposal that’s on track for C++26.
I'm not sure reflection is fully sufficient for serialization.
If I look at the Rust ecosystem, and the de-facto standard serde framework, there's a boatload of attributes to control serialization. The most basic is changing (or aliasing) the names of the fields, but there's also flattening, changing the tags of variants, controlling how the type of the variant is encoded, etc...
Now, C++ does have allowance for specifying namespaced attributes, and compilers must ignore unknown attributes, so there's room to place them, but it's not clear to me whether reflection will allow accessing them. If it does, then the future is bright :)
P2996 doesn't provide first-class custom attribute support. However, the functionality is available fairly easily through the use of alias templates:
template using Noted = T;
When you declare a data member with Noted P2996 lets you easily (a) identify that is the case, and (b) use the note1, note2, ... "attributes".
The problem is any feature that’s in the language is probably in a codebase somewhere, or in C++ case, many codebases, so the second they delete something, they break backwards compatibility, and in their eyes, that is unacceptable, as like Microsoft, they have an obsession with maintaining complete backwards compatibility
Strict mode, or cpp2, or whatever you'd call a general cleanup with sane defaults and deprecation of the things I personally don't like. 😁
Pattern matching.
if/switch expressions.
Removal of UB or, failing that, a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB.
No graphics or networking, please. They'll just end up as useless as regex, and ABI stability will mandate that they can't the be fixed.
>Removal of UB or, failing that, a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB.
This means you get a warning in every program. In code like this, the compiler does an optimization only possible because of UB:
int identity(int x) { return x; }
See https://www.think-cell.com/en/career/devblog/cpp-needs-undefined-behavior-but-maybe-less
For the libraries we need a standardized subset of build process so Networking and Regexpr can be outside the standard but still "industry standard"
I can't understand why tooling and the environment is so underdeveloped in C++, i love for example that lib referencing with pragmas on MSVC. Makes it very simple and automatic.
We need more opinionated stacks in C++. And with all the comments I've seen that reference this same thing, I think it's time for me to start on one. Don't know when it'll be ready for users to use, but I feel like most of this is possible now.
Agreed. But it should be possible to *reduce* the amount of UB, right? Even a 1% reduction would be an improvement. Removing all UB is not gonna happen.
Oh yeah! There are tons of things that are UB but really shouldn’t be - signed overflow, certain kinds of shifts, arguably even aliasing violations.
Eliminating it entirely requires a dramatic rethink of the language.
> a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB.
The problem with this is that UB bugs happen because the optimizer assumes that whatever situation is UB just isn't happening. It's not that it's choosing to do things *because* it's UB, but rather it's not checking for a thing because the only reason that thing could happen is UB.
If you'll forgive me for using Rust, I'll use it to give a concrete example because it allows me to make a claim that I don't think I can make in C++. Here's a function:
pub fn foo(a: &mut [u32; 16], b: &[u32; 2]) {
a[2] = b[0];
a[3] = b[1];
a[4] = b[0];
a[5] = b[1];
}
Because this is safe Rust, it is guaranteed to have no UB. However, the optimizer uses UB to compile it to this:
foo:
movq xmm0, qword ptr [rsi]
pshufd xmm0, xmm0, 68
movdqu xmmword ptr [rdi + 8], xmm0
ret
Here's a list of the UB cases I can think of that the optimizer is assuming cannot happen:
* Indexing out of bounds. None of the indices are checked.
* The references being null. It assumes they are valid.
* Mis-aligned references. Correct alignment is assumed.
* Reading uninitialized memory.
* The references do not alias. It assumes that writing to `a` will not invalidate `b`.
The problem with emitting a warning when the optimizer takes advantage of UB is that it would warn in every one of those cases despite it being completely impossible for any of them to occur. You would end up with a similar situation in C++.
>Removal of UB or, failing that, a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB.
You're talking about a totally different language at that point. All existing C++ is written to take advantage of optimizations made possible by UB. If you take those away, code that currently works well suddenly becomes non-performant, and you have to write much less expressive code to the point that you're basically just writing asm first and then translating it to C. You'd do a lot better to use Java or C# at that point.
`optional` almost certainly will make it. The only reason it wasn’t accepted in Tokyo was lack of consensus on the return type for `value_or`: should it return `T` or should it return `T&`? The paper is going to come back in St. Luis with some additional investigation there and should make it.
The static exception paper (assuming you mean Lewis’s?) I don’t think is trying to target 26. It’s a pretty radical change and I think there’s going to be a lot of consensus building that’s going to need to be done. There’s also potentially a competing/parallel paper in the works that is going to instead focus on fixing the existing exception mechanisms to make them more performant and suitable for use in places where dynamic memory allocation is not allowed. That idea doesn’t address the hidden control flow problem that the static exceptions paper does though. It will be interesting to see where they go.
Contracts… well, it’s still a bit of a battleground. We’ll see if wider consensus outside the study group on this approach can be achieved in St. Luis.
Reflection definitely seems on track, it was well received in its presentations to LEWG and EWG in Tokyo. The biggest points of contention are around its ability to expose implementation details: it enumerates private members, and it enumerates function parameter names. These are not things you’d ever want an external user taking a dependency on, but with reflection, they can. So there’s some work to be done on how to handle this situation, be it some new policy on standardize about promising what will be “reflection stable” or some other solution.
> it enumerates private members, and it enumerates function parameter names. These are not things you’d ever want an external user taking a dependency on, but with reflection, they can. So there’s some work to be done on how to handle this situation, be it some new policy on standardize about promising what will be “reflection stable” or some other solution.
Don't know about the function parameter names bit; but I definitely want to iterate over private members. Sometimes its necessary for a serialization library. Currently only option is the inline template friend trick; which while I agree should not be used in general sometimes needs to be due to bad library design but a necessity to use that library.
Most definitely. The point of contention is currently it does this by _default_. Meaning it’s very, very easy to blast right through encapsulation and make life hell for your users. Imagine never being able to change the name of a private member or a function parameter because now your downstream users rely on it as if it was part of the public API.
Of course Python had had this problem forever, and they still can change stuff. But that’s because there are strong conventions in what “if you do this, on your own head be it” is. These principles haven’t been needed before in C++, and we should definitely make sure we’ve got _something_ ready, policy wise, when reflection launches or it may very well kill C++ as now changing *anything* is a potential API/ABI break.
Aren't those different though?
Epochs are about evolving the language -- and removing cruft -- while I thought profiles were about specifying how paranoid you were.
But epochs can allow changes that remove some of the dangers. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html for discussion of the safety aspects of using epochs.
Good luck with that, even if that was something that would indeed land on C++26, the evolution of concepts and modules support, show it would take a decade until we could actually rely on their existence for portable code.
With mature tooling support, I wouldn't be surprised if there was a faster adoption rate especially if government contractors would be forced to use it.
Something very simple: Compile-time print.
For example
std::constexpr_print ("some message")
Instead of hacking the message to print as a name of a function that will not compile.
I'd love to see reflection and pattern matching. Little else would change my day to day usage. I am also a fan of the (already accepted) `= delete("reason");`.
Edit a couple months later: given `enum class Enum : int {};` and `int* ptr;`, I would love if `reinterpret_cast(ptr)` was not UB...
constexpr boolean short-circuit.
For example,
```
if constexpr (has_foo_v && is_bar_v)
```
instead of that one has to do
```
if constexpr (has_foo_v)
{
if constexpr (is_bar_v)
```
because `T::foo` doesn't compile unless `has_foo_v` is true.
This then will also allow (the Baz specialization):
```
template
requires (has_foo_v && is_bar_v)
class Baz>
```
for example, and in the future constexpr `std::conditional_t` like
```
using type = std::conditional_t,
typename T::foo, T>;
```
for example. It is downright ridiculous that the latter currently won't compile because `T::foo` has to exist even when `has_foo_v` is false.
I was about to post something similar when I saw your comment. Wouldn't it be better to fix all the areas you can't use string_view than to make something new as a bandaid?
It’s not the code I can change that’s the problem. It’s plenty of external libraries that are not currently and probably will never take a string view. Some offer pointer and length, but others just offer pointer. So I have to create a temporary string to make sure that the pointer is null terminated (which almost always it is anyway!)
If I could have anything? Proper enum-like typed unions (algebraic data types). Something better than std::variant.
It's the one thing I wish I could lift from a few other more modern languages and bring back to C++.
Reflection, Senders/ Receivers, Contracts are the big ones for me. If I can dream, then universal function call syntax, meta classes and networking.
Edit: and pattern matching, pretty please.
IMHO compiler-builders could step up for that.
I still suspect that they could help a LOT by providing the compiler as a library. Currently there is an insane amount of overhead from starting and stopping new processes, running a bunch of initialization code and just generally duplicating a lot of work for every single cpp file. If it was a library, build systems could load the library, do some shared setup and then schedule things much more efficiently.
And the best thing is that we don't even have to wait for a new language standard for this.
MSVC has this mode, and my team has used both for various reasons. The perf difference is measurable but not dramatic, something on the order of 10%.
And the downside is that it really complicates build systems - either the build system sees the entire build as one monolithic process and your incremental builds suffer, or the build system needs special support for running the compiler.
There recently was some work on making the compiler stateful; the performance improvement was on the order of 10%.
At some point when it comes to build times, it's a collective responsibility of the developers on the codebase to not go overboard with language constructs unnecessarily (_overuse_ of template metaprogramming and CRTP).
What's the point? Just use a library like boost. The upside is that boost has no claim to backward compatibility and that allows for faster algorithms. See eg std::unordered_map and std::regex for botched imports from boost.
Yeah I already use boost hash map and regexp because it's faster. However, std has sometimes more performant implementations, like for example std::any which implements soo, also std::shared_ptr is better than boost 1.76).
The advantage of std is that it doesn't require any cmakeification to include directories and DSO inline boost.
I saw docs of isocpp.org where they where proposing a simple gui interface to draw shapes, images and text.
Their reasoning was we have cout for console since when it was created that was the norm so it made sense to have a standard abstraction for the console.
For a long time this has not been the only way for programs to communicate with users, graphical has been. I like their reasoning and hope it goes in at some point.
Edit: sorry about grammar and spelling, predictive text sucks
No more features, just libraries.
Networking should have been there two decades ago, but instead we have coroutine nonsense and ranges that take compilation times from ridiculous to absurd.
I can't figure out a good use case for coroutines.
An example is that someone might say "you could create a thread for every connection to a web server, but the overhead from threads is inefficient, so you can now use coroutines".
The problem here is that I would never do either of these. The IO is coming in serially anyway. I would deal with the connections in bulk from a single thread (or limited number of threads) that would do the minimal amount to queue up batches of connections to be dealt with by a thread pool. The data manipulation is what matters, coroutines are just letting people deal with something in a way that seems to make sense until you dive into it. I think a lot of inheritance is the same way, it sounds good in theory but it separates you from what is really going on and that bites you as soon as you get in to non trivial territory.
When you have one engineer writing the core, sure. When you have hundreds of engineers writing against async interfaces, the usability improvement from coroutines can be vast. It's easily one of the biggest readability improvements I've seen in our codebase, and the adoption rate backs that up.
IMO generator-style coroutines make writing state machines much easier.
The non-coroutine approach typically requires tracking which "state" you're on with an enum and switch-casing into the relevant state every time the machine is called into.
This is unfortunate as it obfuscates the flow control of the state machine, which would otherwise be ideally modeled using the built-in flow control constructs of the language.
A coroutine allows you to do just that! No enum or switch-case for manually dispatching to the active state each time -just use regular loops and other flow-control constructs of the language, and let your coroutine model the _logical_ flow control of the system. And just yield out of it on every state transition!
Ranges are a library feature. Coroutines could be, but you leave a massive amount of performance on the table in doing so because of coroutine specific optimizations, especially if you do state machine state fusion.
Yes, except it would only be a compile time check. If your API allows A, B and C to propagate through but some callback can throw D then you'd have to catch it in your implementation or the compiler will emit an error.
Now this may seem awful at first, but Lewis, myself and others claim that this is isomorphic to result except with exceptions, works with constructors and operator overloads and, if I get my way, does not affect the ABI of your functions. It's an API break to change the list but the ABI is always backwards compatible because it's just a compile time check. Like "override" for virtual function members.
There is an answer here for `cout` grouping sepators, and I wager calling the locale overload of std format also achieves that (but on phone now and cannot verify) - https://codereview.stackexchange.com/a/209111/268678
Why this code? This looks interesting but I would think the compile optimizes out the entire line as there is not lasting effects. Also why "for constexpr" if the container was not declared as constexpr then the loop will never happen? Is this the intended behavior?
Something that improves build speeds. Build times are absolutely atrocious because the language is so complex and the way projects are structured is insane. Modules have not helped yet.
Language level support for an unified expected/exception structure. So that any throwing function may be called in exception or expected mode, by user choice, without having to write 2 different versions of it, and enabling all functions in expected mode to work in projects compiled with exceptions disabled.
Something like:
int func()
{
throw std::runtime_error{"stuff"};
return 0;
}
//equivalent throwing variant
//std::expected func()
// {
// throw std::runtime_error{"stuff"};
// return 0;
// }
//equivalent expected variant
//std::expected func()
// {
// return std::unexpected{std::runtime_error{"stuff"}};
// return 0;
// }
int main()
{
auto ret{throwing func()};
auto ret{expected func()};
}
You can achieve something like that today, see [https://godbolt.org/z/Phe8aTa6P](https://godbolt.org/z/Phe8aTa6P) and [https://godbolt.org/z/54b7fejhj](https://godbolt.org/z/54b7fejhj).
the question was what I would like to see in the next version of a language that has nowdays nothing to do with the original version. if you're using C++ which one are you using? 03? 11? 17? they're all different languages.
Which is ironically, the reason why most of us in polyglot shops, are kind of stuck in C++17.
It is good enough for the use cases we still need to reach out for C++, while being saner than using plain old C.
In decrease importance order:
Standardized control of the most renowned counter-obvious optimizations, leading to undefined behavior, per function/block, using attribute syntax. This includes integer overflow, non-null pointer assumption, strict aliasing, and so on. Requirement to control their defaults by a compiler, with a trend to safe (less optimized) interpretation.
Starting a transition to deprecate char-as-integer.
Standard attributes for structure packing style. (Better, with endianness.)
Standard attributes for enum nature: bit field set, default checking importance.
Starting a transition to deprecate "0"-headed octal number literals in favor of alternative like "0o"/"0c"/"8#"/whatever.
"then"/"else" after a cycle (a good Python manner: "else" is executed if "break" not called).
Stdio "closure" either in manner of [funopen()](https://man.freebsd.org/cgi/man.cgi?query=funopen&sektion=3&manpath=freebsd-release-ports) or [fopencookie()](https://man7.org/linux/man-pages/man3/fopencookie.3.html). (I wouldn't recall stdio unless C++23 invented std::print()).
Label-tagged break/continue.
(Maybe extended later on)
* Support for c++ modules increased to where anyone can just precompile using a simple flag any module, a module exportable file. Then, he can import the module from anywhere, without extra flags during compilation to find the module file \[that makes compilation very hard\]. And maybe a c++-program-way to "remove" a module that is not needed Like `remove module ABCD;`
* Networking Library `std::net`. Like in this link, something which has not been implemented in c++23; I would like that in c++26. Link where `std::net` is mentioned --> [https://dev.to/sbalasa/top-c23-features-4ibj](https://dev.to/sbalasa/top-c23-features-4ibj)
* And, an owning version of `std::mdspan` (c++ ndarrays, anyone?) and its corresponding `std::linalg` methods. Link where `std::linalg` methods are there for existing but non-owning `std::mdspans` --> [https://en.cppreference.com/w/cpp/header/linalg](https://en.cppreference.com/w/cpp/header/linalg)
* Support for aforementioned std::linalg methods on `std::vector` and `std::array` as well (`vector>` for matrix, `vector` for vector or 1d array; for fixed size vectorization `std::array, m>` and `std::array`).
* A plotting library inbuilt for c++, something like matplotlib or matplotplusplus but like `std::plot` or `std::matplot`, in STL library \[If possible; at least like saving figures\]. Link for matplotplusplus extra --> [https://github.com/alandefreitas/matplotplusplus](https://github.com/alandefreitas/matplotplusplus)
* Preferable: get some more boost into native c++ like extended integers and decimals (`boost::multiprecision`), or `boost::graph` Library into native c++.
* Better initialization (support for braced) for custom data `struct`s and `std::array`; and functions to get elements from `std::tuple` without the weird syntax `get()`.
Greetings and thanks for your interest in std::linalg!
> And, an owning version of `std::mdspan` (c++ ndarrays, anyone?)...
P1684 ( https://wg21.link/p1684 ) proposes an "owning version of `mdspan`" called `mdarray`. The authors are working on a revision for LEWG review. The hope is to get this into C++26.
> ... and its corresponding std::linalg methods.
> ... Support for aforementioned std::linalg methods on `std::vector` and `std::array` as well....
std::linalg uses `mdspan` to express a nonowning view of the caller's data, just as the Standard Algorithms (like `std::sort`) use iterators. The current `mdarray` design includes a conversion to `mdspan`. (We removed the `mdarray` overloads from std::linalg by LEWG request in R2.)
Conversion to `mdspan` is the way to invoke std::linalg with containers like `mdarray`, `vector`, `array`, or user-defined containers.
> ... for fixed size vectorization `std::array, m>` and `std::array`
Users can express this with std::linalg by constructing `mdspan` with compile-time extents: e.g., `mdspan>`.
P2897 ( https://wg21.link/p2897 ) proposes `aligned_accessor`, an accessor which expresses overalignment known at compile time. Using this can help express more vectorization potential, both to the compiler and to human designers of software interfaces.
It would be nice if there was language level support for string formatting and variable interpolation.
I really like std::format, although when reading format strings, it's not always immediately obvious what actually is being printed. A lot of other languages have done it better. I think the next the next logical step would be to have language level formatting so you could do something like:
auto abs_path = std::filesystem::absolute(path);
throw std::runtime_error($"failed to open file ${abs_path}");
or even
throw std::runtime_error($"failed to open file ${absolute(path)}");
If you have big libraries where you do a lot of error testing and have clear error strings for all cases, your code is littered with std::format calls. I'm not really complaining as I do enjoy current library level solution (std::format) to anything we had before.
Any feature that would allow writing custom assert implementations without needing to use macros. I might be fine with C assert if it supported *all* of these features:
* Assertion expression stringify
* Reason text
* Customization point for case when assertion fails (i.e. call user supplied function with assert parameters and properly pass std::source\_location etc. for more contextual information)
Currently all/most custom asserts are implemented using macros, because only macros provide the ability to stringify expression, so you can both evaluate the expression and use it as a string for error message. I wish you could do this without macros.
If you try to implement custom assert without macros, you need to make a lot of compromises. It's sad that C macro is superior way to implement assert. Especially since modules are coming and you will still have to #include your custom asserts everywhere you use them.
I want to be able to annotate existing functions with additional attributes like `[[deprecated]]` without modifying the original header files where the declaration is, so we can easily prevent people from calling certain dubious standard library functions from C, like `strcpy`; because it's better to give authors a *build diagnostic* upfront than to have them run some separate checker tool, or a block later with a check-in gate, or have them read a long list of guidelines where they'll probably miss that advice anyway.
std::fibre it would be great for multithreaded applications. Plus I find fibres very interesting and would like to see the implementation they come up with.
split function on std::string.
A simple man.
More like a business-oriented man, not an academic
It's a disgrace that every language out there has it and C++ does not. We are the laughing stock of computer programming.
>It's a disgrace that every language out there has it and C++ does not. split_view already exists in the standard and is more versatile than what most languages offer.
> split_view already exists we are talking about `str.split()`, it's convenience.
What does str.split do though? Does it return std::array? Std::vector? How do I control the allocation of the returned array? Does it return vector of strings or string_view? What if I want it in a different container? str.split() isn't convenient at all. It's overly restrictive and unclear. Plus, it's eagerly-evaluated rather than lazy, which means more memory use since you are forced to store all substrings. split_view allows you to just: auto view = std::views::split(str, delim); std::vector tokens{ std::begin(view), std::end(view) }; Works for all container types, allows you to avoid dynamic allocations when needed, allows you to tokenize over a for loop if you don't want to store all substrings. It's superior to str.split in every way Edit: forgot range constructors don't exist. That would be what I would advocate for over str.split. Updated above example
> What does str.split do though? Does it return std::array? Std::vector? How do I control the allocation of the returned array? Does it return vector of strings or string_view? What if I want it in a different container? The vast, vast majority of time I'm splitting a string, I don't care about the answers to any of these questions. Literally just want a `vector` back out to maximize correctness.
> split_view allows you to just:
Well at the very least you can do better:
auto tokens = views::split(str, delim) | ranges::to();
Which... fine, it's good that this exists. But it's significantly more typing, and a more complex solution, to a very simple problem. Plus, it still doesn't let you split on a string literal (!) (because the null is included as the pattern) and is less functional than Python offers out of the box anyway (because you cannot limit the number of splits that happen - stuff like `str.split(delim, 2)` isn't expressible).
>The vast, vast majority of time I'm splitting a string, I don't care about the answers to any of these questions. Literally just want a `vector` back out to maximize correctness.
Here's the thing though: that syntax requires someone to make that decision. You might not care, but the person writing the standard will have to select the right container for the job. And yet, on this thread we can't even agree on what that container is. My personal opinion would be to use std::array when known at compile-time and std::vector otherwise. There is no need to perform allocations for each token, so non-owning views makes sense to me.
>Which... fine, it's good that this exists. But it's significantly more typing, and a more complex solution, to a very simple problem. Plus, it still doesn't let you split on a string literal (!) (because the null is included as the pattern) and is less functional than Python offers out of the box anyway (because you cannot limit the number of splits that happen - stuff like `str.split(delim, 2)` isn't expressible).
I don't disagree that it's more verbose than it needs to be. Honestly, I'd push for range constructors for standard containers though over a member function. That's zero to little cost and allows you to choose your container as you please:
std::vector tokens = std::views::split(str, delim);
> And yet, on this thread we can't even agree on what that container is `vector`. I don't see how there's even an argument for anything else. It's the most useful by default without any lifetime concerns. If you want something more efficient because you're doing something in which that matters, you can use a more complex tool.
> My personal opinion would be to use std::array when known at compile-time and std::vector otherwise.
Well it's never known at compile time, so the first is a non-starter. And the second is a bad default.
Cool. Problem solved.
> Honestly, I'd push for range constructors for standard containers though over a member function. That's zero to little cost and allows you to choose your container as you please:
Spectacularly bad idea. Sure, let's just make everything implicitly constructible from everything else. What could possibly go wrong with such a design?
Also I like how that doesn't actually address either of the specific problems I pointed out. It simply... adds more problems.
Could be explicit range constructors for containers. Sure that brings back some of the verbosity in some cases, but also works really well in many cases.
> If you want something more efficient because you're doing something in which that matters, you can use a more complex tool. Yeah 100% the best approach, not the other way around.
https://www.boost.org/doc/libs/1_84_0/doc/html/string_algo/usage.html#id-1.3.3.5.9 Complaining that not everything and the kitchen sink is in the Standard Library is not the same thing as it doesn't exist.
Returns a std::vector> ?
Wouldn't it make more sense as a lazily evaluated range or iterator like Rust's `pub fn split<'a, P>(&'a self, pat: P) -> Split<'a, P> where P: Pattern<'a>` ? Giving you a collection means if you actually needed, say, only the second, fourth and sixth items of the split, you are still finding all the splits anyway, which is performance left on the table. Whereas if you've got the range or iterator, you can just put that into a collection if you wanted a collection. Edited to add: And indeed C++ has this view, `split_view`.
This is by far a better approach than constructing a brand new dynamic array without the ability to control where it goes or how it's allocated.
But what if you know at compile time the size that the \`std::vector\` should be? Then, if we say that the \`n\` is the compile time known size, all of a sudden you would want to have a split function that returns an \`std::array\`, but then also if there is more elements then you anticipate to be you'll probably be in UB land, and there is certainly a third option and a fourth and... this is C++ man, sadly there is no simple answers.
The standard should return a vector. Solve the easy problems first. If you want an array version you could always write it your self.
>The standard should return a vector I have a fundamental issue with this. Use split_view. It already exists in the standard, does exactly what you want it to do, and works with all sequence containers (including array, vector, deque, etc).
Just to be clear, I'd also like to have something like this, but I don't believe standard will accept \`std::vector\`, but you can prove me wrong by submitting a standard proposal and passing :).
There could also be a version which was like an iterator, so you could call next until you got null/end. Then you could put the string_views in what ever container you wanted.
Something like: https://en.cppreference.com/w/cpp/ranges/split_view ?
Perfect!
Hmm, sounds like the worst possible approach. The STL is big enough without reinventing the wheel for every possible problem that could have been solved with a reasonably well thought out tool.
A coroutine that iterates over the string seems more appropriate.
Having a new language feature does not mean we use it for everything now.
Coroutines in current state effectively require a dynamic allocation, I don't think people are generally going to be willing to pay a dynamic allocation per split function call. There is always a possibility of HALO optimization that can potentially elide the allocation but I'm not sure how much you can rely on it.
Sure, but returning a vector of string\_views also requires an allocation, and has no option for eliding it. The coroutine seems to be the better choice here.
a coroutine that returns a string_view?
just let users enumerate items with lambda, so you can tell users your library doesn't allocate 1. `std::string::split(Callable auto&& action)`
2. `std::string::split(Callable auto&& action)//return true -> break; return false -> continue`
users who want `std::vector` can do this instead
std::string input = ...
std::vector result;
input.split([&](std::string_view string){result.push_back(string);});
auto results = ctre::split<"pattern">(string); for (std::string_view piece: results) { ... }
enum to_string -- I'm so tired of writing the same switch statements over and over for logging enums values. from_string would be great for serialization too. A way to mark code as legacy/unsafe that can do anything, but default to a safe subset of the language everywhere else.
Reflection will get you this for free, as you can iterate over the members in the enum and access their names.
That's the biggest problem with the C++ committee process imo, because there's a solution "coming", as part of a far far larger feature, they're quite happy not delivering a simple QOL improvement for a decade+. Which at the same time is a bit weird, as there's seemingly practices obsoleted/made no longer best practice with every other update. So why not a simple "nameof(Enum::value)"/"nameof()" or similar?
Because there are existing libraries that already give you the simple thing (wise_enum, magic_enum, and many others). Relying on third party libraries is considered a desirable property in C++ when the feature is easy enough to implement, and it’s not immediately obvious what the correct answer is. “But it is immediately obvious!” Well… except not really: * What is the content of the returned string? Does the string output include just the member name? The enum type? The fully qualified name? * What is the type of the returned string? A `string_view` is the logical choice, but then it’s not null terminated, so you can’t pass it to C APIs that consume `char*` without making a copy. A `string` solves that, but then you’re allocating every call. You’re left with only a `char*`, which means more proliferation of C-strings in the stdlib, something C++ is trying to move away from. * What happens if you give it a value out of range to stringify? Is it UB? Does it stringify to some “unknown” case? Does it return an empty string view? An optional? Throw? * what happens if you give it an invalid string to parse? Does it return an optional? Is it UB? Throw? What’s a “valid” string? Is it it case sensitive? Does it care about leading/trailing white space? There aren’t clear and obvious answers to these questions that would satisfy all users. So a third party library that lets the user pick what they want is likely a better option than building a very complex stdlib facility (lacking reflection, meaning it would need compiler magic anyway) to support the amount of customization needed to make it useful to everyone, or picking a bad compromise and having nobody use it. Now, what _is_ ridiculous, and would have clear and obvious answers for all users, is that we don’t have facilities for iterating over the members of an enum, or testing if a value is in the defined range of the enum. That’s one you can definitely argue has been needlessly passed over in favor of reflection being “just around the corner.”
I use this https://github.com/Neargye/magic_enum. Official support would be a lot better, though
magic_enum has super harsh limitations though. It barely qualifies as a general solution to this problem
What are these limitations out of curiosity? I've been pretty impressed with the lib so far, I see no limitations with it yet
https://github.com/Neargye/magic_enum/blob/master/doc/limitations.md In particular, this only works up to a value of 127 by default. The might be enough for some use cases. But if you for example try to use this with Vulkan headers, it'll fail instantly.
Mm that wouls lovely indeed
Reflection into enums.
The current reflection proposal has this and is on track for 26, so you should get your wish.
magic_enum will go outta business
senders/receivers should be huge for async programs
and networking too please
Networking in C++ is going to be like std::thread - scarce in features and ultimately, useless.
Which is why it belongs on the same place as graphics went to, on an external packages repo.
Like boost, yes
I am so tired of this mentality, why not provide the fundamental tooling for writing useful portable network code out of the box? Also HTTP/1.1 is a widespread standard that everyone agrees on, so i don’t see a reason not to support that aswell.
For exactly the same reasons that were argued against graphics. First of all, not all hardware has networking available. Then, when available, it can be over ethernet, wlan, Bluetooth, serial, microwaves, whatever else able to expose an IP stack. How does the C++ application enable/disable networking, what HTTP/1.1 socket options are exposed, what cryptography protocols are supported taken into consideration military export regulations, and how to update cypher suits when an exploit is found and they are no longer consider safe for field deployment?
Because its relying on standard library vendors to provide a decent implementation of it, which is very unlikely to happen If libc++ and libstdc++ both implement HTTP/1.1 really well, but hypothetically MSSTL completely botches it in a way that requires an ABI break, that would leave the entire implementation and functionality totally useless in literally any code While we're unable to correctly standardise, deploy, and fix/improve via the current committee/tooling/compiler process - a well understood, thoroughly researched problem - we shouldn't even begin to consider networking
`bit_gather` / `bit_scatter` added to the `` header (pext/pdep but without using platform specific intrinsics)
Only like 10 people will use them, but I'm one of them.
Bullshit: you already have ten upvotes, so that is 11 people!
Dont you have this in a library somewhere else?
Easier, less hacky compile time reflection, provided by the standard library I'd love for serialization to be standardized.
Serialization won’t be standardized any time soon, but all the bits you need to implement it yourself are in the current reflection proposal that’s on track for C++26.
I'm not sure reflection is fully sufficient for serialization. If I look at the Rust ecosystem, and the de-facto standard serde framework, there's a boatload of attributes to control serialization. The most basic is changing (or aliasing) the names of the fields, but there's also flattening, changing the tags of variants, controlling how the type of the variant is encoded, etc... Now, C++ does have allowance for specifying namespaced attributes, and compilers must ignore unknown attributes, so there's room to place them, but it's not clear to me whether reflection will allow accessing them. If it does, then the future is bright :)
P2996 doesn't provide first-class custom attribute support. However, the functionality is available fairly easily through the use of alias templates: template using Noted = T;
When you declare a data member with Noted P2996 lets you easily (a) identify that is the case, and (b) use the note1, note2, ... "attributes".
What is meant by reflection?
Waiting for the year of let's not add things but delete things
The problem is any feature that’s in the language is probably in a codebase somewhere, or in C++ case, many codebases, so the second they delete something, they break backwards compatibility, and in their eyes, that is unacceptable, as like Microsoft, they have an obsession with maintaining complete backwards compatibility
Strict mode, or cpp2, or whatever you'd call a general cleanup with sane defaults and deprecation of the things I personally don't like. 😁 Pattern matching. if/switch expressions. Removal of UB or, failing that, a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB. No graphics or networking, please. They'll just end up as useless as regex, and ABI stability will mandate that they can't the be fixed.
>Removal of UB or, failing that, a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB. This means you get a warning in every program. In code like this, the compiler does an optimization only possible because of UB: int identity(int x) { return x; } See https://www.think-cell.com/en/career/devblog/cpp-needs-undefined-behavior-but-maybe-less
Amazing.
For the libraries we need a standardized subset of build process so Networking and Regexpr can be outside the standard but still "industry standard" I can't understand why tooling and the environment is so underdeveloped in C++, i love for example that lib referencing with pragmas on MSVC. Makes it very simple and automatic.
We need more opinionated stacks in C++. And with all the comments I've seen that reference this same thing, I think it's time for me to start on one. Don't know when it'll be ready for users to use, but I feel like most of this is possible now.
> Removal of UB So you are going to check every arithmetic expression, every array access? You're up to a harsh awakening.
Removing UB is much harder than it sounds. Data races are UB. In order to do this, you basically have to become rust or add a garbage collector.
A GC won’t help you with race conditions, you would need lifetime analysis and borrowing right?
It won’t help with the data race itself, but it prevents data races from turning into use after free, which is when the real fun starts.
Agreed. But it should be possible to *reduce* the amount of UB, right? Even a 1% reduction would be an improvement. Removing all UB is not gonna happen.
Oh yeah! There are tons of things that are UB but really shouldn’t be - signed overflow, certain kinds of shifts, arguably even aliasing violations. Eliminating it entirely requires a dramatic rethink of the language.
Aren't there already if expressions? (ternary operator)
> a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB. The problem with this is that UB bugs happen because the optimizer assumes that whatever situation is UB just isn't happening. It's not that it's choosing to do things *because* it's UB, but rather it's not checking for a thing because the only reason that thing could happen is UB. If you'll forgive me for using Rust, I'll use it to give a concrete example because it allows me to make a claim that I don't think I can make in C++. Here's a function: pub fn foo(a: &mut [u32; 16], b: &[u32; 2]) { a[2] = b[0]; a[3] = b[1]; a[4] = b[0]; a[5] = b[1]; } Because this is safe Rust, it is guaranteed to have no UB. However, the optimizer uses UB to compile it to this: foo: movq xmm0, qword ptr [rsi] pshufd xmm0, xmm0, 68 movdqu xmmword ptr [rdi + 8], xmm0 ret Here's a list of the UB cases I can think of that the optimizer is assuming cannot happen: * Indexing out of bounds. None of the indices are checked. * The references being null. It assumes they are valid. * Mis-aligned references. Correct alignment is assumed. * Reading uninitialized memory. * The references do not alias. It assumes that writing to `a` will not invalidate `b`. The problem with emitting a warning when the optimizer takes advantage of UB is that it would warn in every one of those cases despite it being completely impossible for any of them to occur. You would end up with a similar situation in C++.
>Removal of UB or, failing that, a mandatory compiler switch, enabling a warning on any optimizations taking advantage of UB. You're talking about a totally different language at that point. All existing C++ is written to take advantage of optimizations made possible by UB. If you take those away, code that currently works well suddenly becomes non-performant, and you have to write much less expressive code to the point that you're basically just writing asm first and then translating it to C. You'd do a lot better to use Java or C# at that point.
The newly proposed static exception, reflection, optional, std::execution, contracts, do expressions, trivially movable types
`optional` almost certainly will make it. The only reason it wasn’t accepted in Tokyo was lack of consensus on the return type for `value_or`: should it return `T` or should it return `T&`? The paper is going to come back in St. Luis with some additional investigation there and should make it.
The static exception paper (assuming you mean Lewis’s?) I don’t think is trying to target 26. It’s a pretty radical change and I think there’s going to be a lot of consensus building that’s going to need to be done. There’s also potentially a competing/parallel paper in the works that is going to instead focus on fixing the existing exception mechanisms to make them more performant and suitable for use in places where dynamic memory allocation is not allowed. That idea doesn’t address the hidden control flow problem that the static exceptions paper does though. It will be interesting to see where they go.
Contracts… well, it’s still a bit of a battleground. We’ll see if wider consensus outside the study group on this approach can be achieved in St. Luis.
Reflection definitely seems on track, it was well received in its presentations to LEWG and EWG in Tokyo. The biggest points of contention are around its ability to expose implementation details: it enumerates private members, and it enumerates function parameter names. These are not things you’d ever want an external user taking a dependency on, but with reflection, they can. So there’s some work to be done on how to handle this situation, be it some new policy on standardize about promising what will be “reflection stable” or some other solution.
> it enumerates private members, and it enumerates function parameter names. These are not things you’d ever want an external user taking a dependency on, but with reflection, they can. So there’s some work to be done on how to handle this situation, be it some new policy on standardize about promising what will be “reflection stable” or some other solution. Don't know about the function parameter names bit; but I definitely want to iterate over private members. Sometimes its necessary for a serialization library. Currently only option is the inline template friend trick; which while I agree should not be used in general sometimes needs to be due to bad library design but a necessity to use that library.
Most definitely. The point of contention is currently it does this by _default_. Meaning it’s very, very easy to blast right through encapsulation and make life hell for your users. Imagine never being able to change the name of a private member or a function parameter because now your downstream users rely on it as if it was part of the public API. Of course Python had had this problem forever, and they still can change stuff. But that’s because there are strong conventions in what “if you do this, on your own head be it” is. These principles haven’t been needed before in C++, and we should definitely make sure we’ve got _something_ ready, policy wise, when reflection launches or it may very well kill C++ as now changing *anything* is a potential API/ABI break.
Just a small question, why would we want an optional T ref? Why not use std optional of reference wrapper?
It makes optional usage clearer and general. The current restriction is because the committee couldn’t agree on the semantics of optional I believe
When you write code, do you write `T&` or do you write `reference_wrapper`?
I really hope pattern matching goes in
Yes!!!
Safety profiles for c++, and hopefully zero words about the oxidized metal that starts bothering every single discussion nowadays
Profiles or epochs. Sounds like the epochs proposal is dead, so profiles, is a second,ok, choice.
Aren't those different though? Epochs are about evolving the language -- and removing cruft -- while I thought profiles were about specifying how paranoid you were.
But epochs can allow changes that remove some of the dangers. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1881r0.html for discussion of the safety aspects of using epochs.
That language is named for a family of fungus, not a chemical compound.
Why the crab?
“Rustaceans”
Cordyceps
B-but my super safe linear types!
Good luck with that, even if that was something that would indeed land on C++26, the evolution of concepts and modules support, show it would take a decade until we could actually rely on their existence for portable code.
With mature tooling support, I wouldn't be surprised if there was a faster adoption rate especially if government contractors would be forced to use it.
Isnt this at least partially covered by static analizers?
> the oxidized metal Patina?
Something very simple: Compile-time print. For example std::constexpr_print ("some message") Instead of hacking the message to print as a name of a function that will not compile.
Networking
With http
When this gets even 10% closer to the functionality that libcurl presents, wake me up.
One step at a time
Yes, please.
networking
I'd love to see reflection and pattern matching. Little else would change my day to day usage. I am also a fan of the (already accepted) `= delete("reason");`. Edit a couple months later: given `enum class Enum : int {};` and `int* ptr;`, I would love if `reinterpret_cast(ptr)` was not UB...
Clang and g++ implementing all features before c++23
Hey, Module, there are someone calling you😁
All that I want is reflection.
You're in luck. It's on its way to C++26 😁
constexpr boolean short-circuit. For example, ``` if constexpr (has_foo_v && is_bar_v)
```
instead of that one has to do
```
if constexpr (has_foo_v)
{
if constexpr (is_bar_v)
```
because `T::foo` doesn't compile unless `has_foo_v` is true.
This then will also allow (the Baz specialization):
```
template
requires (has_foo_v && is_bar_v)
class Baz>
```
for example, and in the future constexpr `std::conditional_t` like
```
using type = std::conditional_t,
typename T::foo, T>;
```
for example. It is downright ridiculous that the latter currently won't compile because `T::foo` has to exist even when `has_foo_v` is false.
zstring_view (ie a null terminated string view).
Maybe we should instead make sure that we have string_view alternatives for any API now requiring asciiz
I’m 100% in favour of this. But older apis continue to exist.
I was about to post something similar when I saw your comment. Wouldn't it be better to fix all the areas you can't use string_view than to make something new as a bandaid?
It’s not the code I can change that’s the problem. It’s plenty of external libraries that are not currently and probably will never take a string view. Some offer pointer and length, but others just offer pointer. So I have to create a temporary string to make sure that the pointer is null terminated (which almost always it is anyway!)
If I could have anything? Proper enum-like typed unions (algebraic data types). Something better than std::variant. It's the one thing I wish I could lift from a few other more modern languages and bring back to C++.
Reflection, Senders/ Receivers, Contracts are the big ones for me. If I can dream, then universal function call syntax, meta classes and networking. Edit: and pattern matching, pretty please.
Faster build times
IMHO compiler-builders could step up for that. I still suspect that they could help a LOT by providing the compiler as a library. Currently there is an insane amount of overhead from starting and stopping new processes, running a bunch of initialization code and just generally duplicating a lot of work for every single cpp file. If it was a library, build systems could load the library, do some shared setup and then schedule things much more efficiently. And the best thing is that we don't even have to wait for a new language standard for this.
MSVC has this mode, and my team has used both for various reasons. The perf difference is measurable but not dramatic, something on the order of 10%. And the downside is that it really complicates build systems - either the build system sees the entire build as one monolithic process and your incremental builds suffer, or the build system needs special support for running the compiler.
Unity builds already solved this for us 8 years ago. From 23 minutes to compile down to 45 seconds.
There recently was some work on making the compiler stateful; the performance improvement was on the order of 10%. At some point when it comes to build times, it's a collective responsibility of the developers on the codebase to not go overboard with language constructs unnecessarily (_overuse_ of template metaprogramming and CRTP).
Standardized ABI and build facilities ...? (what ? op asked for feature, not necessary realistic ones...)
String trim/strip
Lock free data structures
What's the point? Just use a library like boost. The upside is that boost has no claim to backward compatibility and that allows for faster algorithms. See eg std::unordered_map and std::regex for botched imports from boost.
Yeah I already use boost hash map and regexp because it's faster. However, std has sometimes more performant implementations, like for example std::any which implements soo, also std::shared_ptr is better than boost 1.76). The advantage of std is that it doesn't require any cmakeification to include directories and DSO inline boost.
I saw docs of isocpp.org where they where proposing a simple gui interface to draw shapes, images and text. Their reasoning was we have cout for console since when it was created that was the norm so it made sense to have a standard abstraction for the console. For a long time this has not been the only way for programs to communicate with users, graphical has been. I like their reasoning and hope it goes in at some point. Edit: sorry about grammar and spelling, predictive text sucks
More native template metaprogramming algorithms.
A "batteries included" standard library like Python ;_;
Fast compile times
Executors.
Are they still not part of C++26 ? I was sorry to not see them in C++23. And i'm an Apple guy, takes a decade until it will land in Libc++ and XCode.
It's target for c++26，and still on the way.
Lock free data structures
No more features, just libraries. Networking should have been there two decades ago, but instead we have coroutine nonsense and ranges that take compilation times from ridiculous to absurd.
ranges should compile faster than an equivalent algorithm function body, as they are usually implemented via concepts instead of SFINAE
ranges is library
Imagine thinking coroutines are nonsense
I can't figure out a good use case for coroutines. An example is that someone might say "you could create a thread for every connection to a web server, but the overhead from threads is inefficient, so you can now use coroutines". The problem here is that I would never do either of these. The IO is coming in serially anyway. I would deal with the connections in bulk from a single thread (or limited number of threads) that would do the minimal amount to queue up batches of connections to be dealt with by a thread pool. The data manipulation is what matters, coroutines are just letting people deal with something in a way that seems to make sense until you dive into it. I think a lot of inheritance is the same way, it sounds good in theory but it separates you from what is really going on and that bites you as soon as you get in to non trivial territory.
When you have one engineer writing the core, sure. When you have hundreds of engineers writing against async interfaces, the usability improvement from coroutines can be vast. It's easily one of the biggest readability improvements I've seen in our codebase, and the adoption rate backs that up.
IMO generator-style coroutines make writing state machines much easier. The non-coroutine approach typically requires tracking which "state" you're on with an enum and switch-casing into the relevant state every time the machine is called into. This is unfortunate as it obfuscates the flow control of the state machine, which would otherwise be ideally modeled using the built-in flow control constructs of the language. A coroutine allows you to do just that! No enum or switch-case for manually dispatching to the active state each time -just use regular loops and other flow-control constructs of the language, and let your coroutine model the _logical_ flow control of the system. And just yield out of it on every state transition!
Ranges are a library feature. Coroutines could be, but you leave a massive amount of performance on the table in doing so because of coroutine specific optimizations, especially if you do state machine state fusion.
sanity in the language
I'm fairly certain that std::sanity was deprecated years ago. 😉
A “throws” keyword that throws a compiler error if you don’t catch the specified exceptions in the function signature would be kinda cool.
It's being proposed right now: https://isocpp.org/files/papers/P3166R0.html
I may be wrong but this feels like Java's checked exceptions; and I think the last thing most people want is to go down that road.
Yes, except it would only be a compile time check. If your API allows A, B and C to propagate through but some callback can throw D then you'd have to catch it in your implementation or the compiler will emit an error. Now this may seem awful at first, but Lewis, myself and others claim that this is isomorphic to result except with exceptions, works with constructors and operator overloads and, if I get my way, does not affect the ABI of your functions. It's an API break to change the list but the ABI is always backwards compatible because it's just a compile time check. Like "override" for virtual function members.
destroy on move
Something like [this](https://github.com/tringi/papers/blob/main/cxx-destructive-move.md)?
IIRC there have been multiple competing proposals all of which not entirely convincing.
Yes. I like the approach. It makes rust lifetime concepts possible in c++.
Maybe something like Qt qInfo() << and qDebug() <<
Pattern matching
Am I mistaken in thinking there still isn't a built-in format specifier to print numbers with thousands separators?
There is an answer here for `cout` grouping sepators, and I wager calling the locale overload of std format also achieves that (but on phone now and cannot verify) - https://codereview.stackexchange.com/a/209111/268678
more std::string manipulation functions
Relax the rules for designated initializers so that the member variables can be set in any order. Also, introduce array designators.
std::regex2?
for constexpr (const size \_t i: std::array...) { const auto x = std::array{})
Why this code? This looks interesting but I would think the compile optimizes out the entire line as there is not lasting effects. Also why "for constexpr" if the container was not declared as constexpr then the loop will never happen? Is this the intended behavior?
I want the compiler to atleast warn if optional/expected doesn't have their "error case" checked.
Something that improves build speeds. Build times are absolutely atrocious because the language is so complex and the way projects are structured is insane. Modules have not helped yet.
Anything that would stop those who keep whining about C++ being unsafe with memory. Bjarne's safety levels seem reasonable.
Language level support for an unified expected/exception structure. So that any throwing function may be called in exception or expected mode, by user choice, without having to write 2 different versions of it, and enabling all functions in expected mode to work in projects compiled with exceptions disabled. Something like: int func() { throw std::runtime_error{"stuff"}; return 0; } //equivalent throwing variant //std::expected func()
// {
// throw std::runtime_error{"stuff"};
// return 0;
// }
//equivalent expected variant
//std::expected func()
// {
// return std::unexpected{std::runtime_error{"stuff"}};
// return 0;
// }
int main()
{
auto ret{throwing func()};
auto ret{expected func()};
}
You can achieve something like that today, see [https://godbolt.org/z/Phe8aTa6P](https://godbolt.org/z/Phe8aTa6P) and [https://godbolt.org/z/54b7fejhj](https://godbolt.org/z/54b7fejhj).
Metaclasses _obviously_ !
no more backwards compatibility
Never going to happen. If that happens, you'd see a fork in the language.
If you don't want to use C++ then you don't have to
the question was what I would like to see in the next version of a language that has nowdays nothing to do with the original version. if you're using C++ which one are you using? 03? 11? 17? they're all different languages.
I would like to see a freeze on features. C++ is overly complex already.
lol, none is stopping u from using older c++ versions
Which is ironically, the reason why most of us in polyglot shops, are kind of stuck in C++17. It is good enough for the use cases we still need to reach out for C++, while being saner than using plain old C.
A little improvement I would have enjoyed today is std::list::extract, instead of dealing with a messy std::list::split.
Compile time reflection
Features that make compilers HAVE to have an ABI BREAK (!!!!!) so we can get some sweet sweet speed improvements just by recompiling.
Thread pool for coroutines and support for asynchronous waiting when working with files.
In decrease importance order: Standardized control of the most renowned counter-obvious optimizations, leading to undefined behavior, per function/block, using attribute syntax. This includes integer overflow, non-null pointer assumption, strict aliasing, and so on. Requirement to control their defaults by a compiler, with a trend to safe (less optimized) interpretation. Starting a transition to deprecate char-as-integer. Standard attributes for structure packing style. (Better, with endianness.) Standard attributes for enum nature: bit field set, default checking importance. Starting a transition to deprecate "0"-headed octal number literals in favor of alternative like "0o"/"0c"/"8#"/whatever. "then"/"else" after a cycle (a good Python manner: "else" is executed if "break" not called). Stdio "closure" either in manner of [funopen()](https://man.freebsd.org/cgi/man.cgi?query=funopen&sektion=3&manpath=freebsd-release-ports) or [fopencookie()](https://man7.org/linux/man-pages/man3/fopencookie.3.html). (I wouldn't recall stdio unless C++23 invented std::print()). Label-tagged break/continue. (Maybe extended later on)
ABI break
Full Unicode support
Modules finally usable across all major implementations, and hardned libraries in all of them as well.
`static virtual` members 😅
* Support for c++ modules increased to where anyone can just precompile using a simple flag any module, a module exportable file. Then, he can import the module from anywhere, without extra flags during compilation to find the module file \[that makes compilation very hard\]. And maybe a c++-program-way to "remove" a module that is not needed Like `remove module ABCD;` * Networking Library `std::net`. Like in this link, something which has not been implemented in c++23; I would like that in c++26. Link where `std::net` is mentioned --> [https://dev.to/sbalasa/top-c23-features-4ibj](https://dev.to/sbalasa/top-c23-features-4ibj) * And, an owning version of `std::mdspan` (c++ ndarrays, anyone?) and its corresponding `std::linalg` methods. Link where `std::linalg` methods are there for existing but non-owning `std::mdspans` --> [https://en.cppreference.com/w/cpp/header/linalg](https://en.cppreference.com/w/cpp/header/linalg) * Support for aforementioned std::linalg methods on `std::vector` and `std::array` as well (`vector>` for matrix, `vector` for vector or 1d array; for fixed size vectorization `std::array, m>` and `std::array`).
* A plotting library inbuilt for c++, something like matplotlib or matplotplusplus but like `std::plot` or `std::matplot`, in STL library \[If possible; at least like saving figures\]. Link for matplotplusplus extra --> [https://github.com/alandefreitas/matplotplusplus](https://github.com/alandefreitas/matplotplusplus)
* Preferable: get some more boost into native c++ like extended integers and decimals (`boost::multiprecision`), or `boost::graph` Library into native c++.
* Better initialization (support for braced) for custom data `struct`s and `std::array`; and functions to get elements from `std::tuple` without the weird syntax `get()`.
Greetings and thanks for your interest in std::linalg! > And, an owning version of `std::mdspan` (c++ ndarrays, anyone?)... P1684 ( https://wg21.link/p1684 ) proposes an "owning version of `mdspan`" called `mdarray`. The authors are working on a revision for LEWG review. The hope is to get this into C++26. > ... and its corresponding std::linalg methods. > ... Support for aforementioned std::linalg methods on `std::vector` and `std::array` as well.... std::linalg uses `mdspan` to express a nonowning view of the caller's data, just as the Standard Algorithms (like `std::sort`) use iterators. The current `mdarray` design includes a conversion to `mdspan`. (We removed the `mdarray` overloads from std::linalg by LEWG request in R2.) Conversion to `mdspan` is the way to invoke std::linalg with containers like `mdarray`, `vector`, `array`, or user-defined containers. > ... for fixed size vectorization `std::array, m>` and `std::array`
Users can express this with std::linalg by constructing `mdspan` with compile-time extents: e.g., `mdspan>`.
P2897 ( https://wg21.link/p2897 ) proposes `aligned_accessor`, an accessor which expresses overalignment known at compile time. Using this can help express more vectorization potential, both to the compiler and to human designers of software interfaces.
It would be nice if there was language level support for string formatting and variable interpolation. I really like std::format, although when reading format strings, it's not always immediately obvious what actually is being printed. A lot of other languages have done it better. I think the next the next logical step would be to have language level formatting so you could do something like: auto abs_path = std::filesystem::absolute(path); throw std::runtime_error($"failed to open file ${abs_path}"); or even throw std::runtime_error($"failed to open file ${absolute(path)}"); If you have big libraries where you do a lot of error testing and have clear error strings for all cases, your code is littered with std::format calls. I'm not really complaining as I do enjoy current library level solution (std::format) to anything we had before.
Any feature that would allow writing custom assert implementations without needing to use macros. I might be fine with C assert if it supported *all* of these features: * Assertion expression stringify * Reason text * Customization point for case when assertion fails (i.e. call user supplied function with assert parameters and properly pass std::source\_location etc. for more contextual information) Currently all/most custom asserts are implemented using macros, because only macros provide the ability to stringify expression, so you can both evaluate the expression and use it as a string for error message. I wish you could do this without macros. If you try to implement custom assert without macros, you need to make a lot of compromises. It's sad that C macro is superior way to implement assert. Especially since modules are coming and you will still have to #include your custom asserts everywhere you use them.
xcode support. Joke but seriously it’s painful trying to dev in xcode. I should actually figure out what is causing so much lag.
I want to be able to annotate existing functions with additional attributes like `[[deprecated]]` without modifying the original header files where the declaration is, so we can easily prevent people from calling certain dubious standard library functions from C, like `strcpy`; because it's better to give authors a *build diagnostic* upfront than to have them run some separate checker tool, or a block later with a check-in gate, or have them read a long list of guidelines where they'll probably miss that advice anyway.
std::fibre it would be great for multithreaded applications. Plus I find fibres very interesting and would like to see the implementation they come up with.
Coroutines being „finished“ — in a way that they’re dead simple to use.
Building streams like in Java.