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

11–20 of 75 posts

Re: C++26: Std:Is_within_lifetime

#11

Post by tw1984 »

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_within_lifetime in the era of AI.

what a bloody load of joke!

Can't wait to see some high accurate coding agents start being able to port C++ code to rust with minimum human interventions to liberate people from the most bureaucratic nonsense in CS history. Some AI native language incorporated with concepts that were too complicated for human would be even better.

it has never been a better time to depreciate dinosaurs like C++!

Re: C++26: Std:Is_within_lifetime

#12

Post by dzdt »

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?

Re: C++26: Std:Is_within_lifetime

#13

Post by IsTom »

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.

Ah, the good old True, False, FileNotFound.

Re: C++26: Std:Is_within_lifetime

#14

Post by raincole »

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?

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.

Re: C++26: Std:Is_within_lifetime

#15

Post by ainiriand »

raincole wrote: post #14
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?

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.

I would love to see the first LLM shot in the foot with C++. I mean it is not like human devs don't do that right?

Re: C++26: Std:Is_within_lifetime

#16

Post by alphazard »

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 languages decay, and the game has been (historically, before LLMs) to pick a language that would be in the sweet spot for the time that you need to use it, while keeping your eye out for something else to switch to once it becomes sufficiently unusable.

Re: C++26: Std:Is_within_lifetime

#18

Post by cataphract »

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.

It was an example. The point was to make untagged unions usable in constant evaluation contexts.

What I was surprised with was that their union code was valid. I thought accessing a union member that was not active was valid in C, but not in C++.

Re: C++26: Std:Is_within_lifetime

#19

Post by cbm-vic-20 »

raincole wrote: post #14
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?

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.

Or, like the Shakespeare programming language.

https://shakespearelang.com/

Re: C++26: Std:Is_within_lifetime

#20

Post by raincole »

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…

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?
Post reply on HN