Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++26: Std:Is_within_lifetime

sandordargo.com

Post reply on HN
Print view View original

21–30 of 75 posts

Re: C++26: Std:Is_within_lifetime

#21

Post by tialaramex »

ephou7 wrote: post #8
matthewkayin wrote: post #4

The problem pointed out in the article seems a little silly. We're adding an entire language feature because someone wanted an optional bool class? Why not just create a uint8_t with three values: OPTIONAL_BOOL_FASLE, OPTIONAL_BOOL_TRUE, OPTIONAL_BOOL_UNDEFINED? Doing so takes the same space as a bool, and could be wrapped in a class if desired to provide a nicer interface.

Exactly my thought. Or a typed enum: enum class uint8_t { NAH, YEAH, OMGWTF }; I'm (fairly) sure there's a good reason for that language feature, but the justification the blog article gives is super weak.

Well, here's Barry's actual proposal paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p26...

The language is the problem, and WG21 hates fixing the language. The really bone headed stuff like "UB? in my Lexer?" got through as a language change and Barry has also had some success with "just fix it" language changes, that's what happened so that C++ can attempt what Rust's MaybeUninit does, but mostly WG21 will take weird new intrinsics in the standard library, as here, over just fixing the programming language.

Re: C++26: Std:Is_within_lifetime

#22

Post by secondcoming »

dzdt wrote: post #12

This 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

Re: C++26: Std:Is_within_lifetime

#23

Post by [deleted] »

matthewkayin wrote: post #4

The problem pointed out in the article seems a little silly. We're adding an entire language feature because someone wanted an optional bool class? Why not just create a uint8_t with three values: OPTIONAL_BOOL_FASLE, OPTIONAL_BOOL_TRUE, OPTIONAL_BOOL_UNDEFINED? Doing so takes the same space as a bool, and could be wrapped in a class if desired to provide a nicer interface.

[deleted]

Re: C++26: Std:Is_within_lifetime

#24

Post by lights0123 »

raincole wrote: post #20
alphazard wrote: post #16

Earlier 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?

Python removes features all the time in 3.x releases. For example, I was not a fan of the distutils removal in 3.12 which broke many legacy but otherwise functional packages. Deprecated functions and classes are also removed from packages regularly.

They do publish removal plans years in advance, e.g. see Python 3.17's plans: https://docs.python.org/3/deprecations/pending-removal-in-3....

Re: C++26: Std:Is_within_lifetime

#25

Post by hypeatei »

alphazard wrote: post #16
worldsavior wrote: post #10

Mature 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…

Rust intentionally keeps its std library small and makes no promises about ABI; it seems to have resisted a lot of pressure to do the opposite from C++ fanatics. I don't agree that the C++ path is inevitable.

Re: C++26: Std:Is_within_lifetime

#26

Post by estimator7292 »

The 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 really do both with the same degree of effectiveness.

I really like C++, and I will probably continue using it forever. But really only the very small subset of the language that applies to my chosen field. I'm a "C with classes" kind of guy and templates and constexpr are pretty rare. Hell, half the time I don't even have stdlib on embedded platforms. It's kind of nice, actually.

Re: C++26: Std:Is_within_lifetime

#27

Post by ethin »

tw1984 wrote: post #11

you 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 extraneous, hard to define problems to the STL? Do you really want to add something way more complicated than a regular expression engine to C++ (networking), with all that entails? Because I certainly don't.

Re: C++26: Std:Is_within_lifetime

#28

Post by yearolinuxdsktp »

tialaramex wrote: post #21
ephou7 wrote: post #8

Earlier quoted context omitted.

Exactly my thought. Or a typed enum: enum class uint8_t { NAH, YEAH, OMGWTF }; I'm (fairly) sure there's a good reason for that language feature, but the justification the blog article gives is super weak.

Well, here's Barry's actual proposal paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p26... The language is the problem, and WG21 hates fixing the language. The really bone headed stuff like "UB? in my Lexer?" got through as a language change and Barry has also had some success with "just fix it" language changes, that's what happened so that C++ can attempt what Rust's MaybeUninit does, but mostly WG…

What do you think the programming language fix would be?

Re: C++26: Std:Is_within_lifetime

#29

Post by Blackthorn »

worldsavior wrote: post #10

Mature 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.

You can just set -std=c++03 and program like the language never evolved if that's your personal preference.

Other than that, there's always an interesting psychology at play in software engineering but it really seems to come out when people talk about C++ for some reason. Complexity is just needless bloat when it's a feature you aren't using, and it's an essential part of the language when it's a feature you are.

Re: C++26: Std:Is_within_lifetime

#30

Post by jasode »

raincole wrote: post #20
alphazard wrote: post #16

Earlier 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?

Examples of C++11, C++17, C++20, C++23 that removed features. Some deep links:

https://en.wikipedia.org/wiki/C%2B%2B11#Features_removed_or_...

https://en.wikipedia.org/wiki/C%2B%2B17#Removed_features

https://en.wikipedia.org/wiki/C%2B%2B20#Removed_and_deprecat...

https://en.wikipedia.org/wiki/C%2B%2B23#Removed_features_and...

Post reply on HN