C++ people will point to this and say *See, C++ is still evolving and we ARE taking memory problems seriously*. You sure are, gramps.
Naming is atrocious indeed.
C++26: Std:Is_within_lifetime
31–40 of 75 posts
Re: C++26: Std:Is_within_lifetime
#32This continues the trend that the C++ language spec is too large for any person to understand, full of opaquely named things for obscure use cases. Maybe when most code is written by LLMs this kind of extension will be appreciated? Because the LLM can manage to get its large head around all of these obscure functionalities and apply them in the appropriate situations?
Since the birth of ChatGPT, people have been talking about if one day LLMs will be trained to write bytecode or even machine code directly, making future code incomprehensible for humans. It'd be funny if it ends up being just C++35.
It is hardly any different from,
C Source code => Tradicional UNIX C compiler => ASM => object file
Now everyone is doing
AI tooling => C Source code => Tradicional UNIX C compiler => ASM => object file
For all pratical purposes, just like using a language like Nim, the workflow exposed to user can hide the middle steps.
Then there is the other take, if you start using agents that can be configured to do tool calling, it is hardly any different from low code applications, doing REST/GraphQL/gRPC calls orchestrated via flow charts, which is exactly what iPaSS tooling are offering nowadays, like Workato, Boomi,...
Re: C++26: Std:Is_within_lifetime
#33The more I interact with consteval and the whole template metaprogramming and codegen paradigm, the more I think it's completely inappropriate to shovel into stdlib. I don't think this should even be part of the language itself, but something more like a linter on top of the C++ language. For most of us it seems you can get good at C++ or metaprogramming. But unless you want to make it your entire career you can't re…
We find constexpr (and associated templates) essential for when we need to avoid branch penalties. It makes the code so much simpler and cleaner than the alternative. I'm glad the language caters to the needs of everyone, even if any individual person (self included) only uses a little bit of it.
Re: C++26: Std:Is_within_lifetime
#34Mature lanagues like CPP should stop adding more features to the language/std. Adding features to the language just makes it more complex, and adding to the std library just adds more overhead, and maybe even security issues.
What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Unless you have a system that says "no" a lot, and occasionally removes features, programming la…
What are you talking about? Rust governance could not be more different from C++.
Re: C++26: Std:Is_within_lifetime
#35Earlier quoted context omitted.
What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Unless you have a system that says "no" a lot, and occasionally removes features, programming la…
Is there ever a successful programming language that occasionally removes features? Like, not just a big, one-time backward-incompatible upgrade, but occasional feature removal?
Java, since Java 9 deprecated for removal really means it.
.NET, the whole .NET Framework to modern (core) .NET migration, left several parts behind, the foor loop semantics change on C#, introduction of field keyword, and with.
Re: C++26: Std:Is_within_lifetime
#36Mature lanagues like CPP should stop adding more features to the language/std. Adding features to the language just makes it more complex, and adding to the std library just adds more overhead, and maybe even security issues.
What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory. Unless you have a system that says "no" a lot, and occasionally removes features, programming la…
Even Go is encountering the same fate, albeit slower. It’s nearly impossible to remove a feature once it has seen adoption, especially without an alternative; whereas there are always patterns that are greatly simplified by some new feature, and when a language becomes large, these patterns become common enough that the absence of said feature becomes annoying.
Re: C++26: Std:Is_within_lifetime
#37assert(std::is_language_getting_too_hairy(&cpp));
Re: C++26: Std:Is_within_lifetime
#38>I scratched my head. Is the link correct?
>It is — and it totally makes sense.
Average C++ enyojer coping mechanism on C++ trend of naming things with the most convoluted (and often wrong) way possible. std::vector, std::monostate, std::unit, etc.
Re: C++26: Std:Is_within_lifetime
#39you really need to hate yourself to still pay attention to such horrible stuff in 2026. 41 years after its invention, C++ still doesn't have networking support in its stdlib. excuses after excuses, they have millions justifications on why the stdlib doesn't need networking. but in the same time, some bureaucratic "committee members" struggling with their midlife crisis want you to waste your life on stuff like Std:Is…
Oh here we go again, someone demanding networking (of all things) in the standard library. Are you next going to demand a GUI toolkit too? Maybe an entire game engine and Vulkan/WebGPU implementation too while we're at it? Just because other languages do it does not mean it is a wise idea for C++ to follow suit. I mean, do I really need to point you to std::regex as an example of what happens when we try to add extra…
I'm not a C++ programmer, and so in a sense I don't care whether they get networking but
1: Some of networking is vocabulary and so it obviously should live in your stdlib, and indeed for C++ it should be in what they call "freestanding", like Rust's core, where core::net::IPv4Addr lives. It is very silly if the software in this cheap embedded device and this PC web browser can't even agree on what an IP address is in 2026.
2: In practice the C++ stdlib is used as a dumping ground for stuff that ought to live in a package manager if C++ was a good language. That was true when networking was first proposed and it's still true now. It's why RCU and Hive are both in C++ 26. Those aren't vocabulary, and they aren't needed by the vast majority of programmers, but their proponents wanted them to be available out of the box and in C++ that means they must live in the stdlib.
Re: C++26: Std:Is_within_lifetime
#40This continues the trend that the C++ language spec is too large for any person to understand, full of opaquely named things for obscure use cases. Maybe when most code is written by LLMs this kind of extension will be appreciated? Because the LLM can manage to get its large head around all of these obscure functionalities and apply them in the appropriate situations?
you don't have to use it
but you will have to read it if someone else uses it.