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

61–70 of 75 posts

Re: C++26: Std:Is_within_lifetime

#61

Post by jcranmer »

alphazard wrote: post #60
jcranmer wrote: post #52

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. Dear lord that is not the case. The C++ standardization process is extremely different from Ru…

This kind of "but for us it's different" thinking is a little amusing. I don't care about the implementation process or the RFCs or what-have-you. If there is a democratic committee of humans that decides what goes in, and there is no bias for minimalism (e.g. 1/3 could strike down a proposal instead of 1/2) then the process will tend towards bloat.

The Rust RFC process requires essentially unanimous consent: there's no formal voting procedure, but the various teams can block any feature from going in.

But sure, keep on saying they're basically the same thing.

Re: C++26: Std:Is_within_lifetime

#62

Post by maleldil »

sebtron wrote: post #9
mFixman wrote: post #3

Is this the first type of sum-type option choosing statement present for C++ unions? I've been waiting for this feature since the year 1978. Still, it's a wasted opportunity not to have a language-level overload to the `switch` statement that allows nice pattern matching. Even with std::is_within_lifetime C++ unions are prone to errors and hard to work with.

Since C++17 there is std::variant https://en.cppreference.com/w/cpp/utility/variant.html

These are not proper sum types, since you're limited to one variant per type.

Re: C++26: Std:Is_within_lifetime

#63

Post by omoikane »

estimator7292 wrote: post #26

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

I am actually glad that more and more of the metaprogramming techniques are built into the language itself, because people are going to try metaprogramming anyways, and their attempts at it are generally less readable without proper compiler support.

Anecdotally, I remember having to review a library written in C++98. It actually worked as promised, but it also did a lot of extremely clever things that were sort of unnecessary if we had just waited for C++11 with type_traits. We got rid of that library later after rewriting all the downstream dependencies.

Re: C++26: Std:Is_within_lifetime

#64

Post by sebtron »

maleldil wrote: post #62
sebtron wrote: post #9

Earlier quoted context omitted.

Since C++17 there is std::variant https://en.cppreference.com/w/cpp/utility/variant.html

These are not proper sum types, since you're limited to one variant per type.

I am not sure what you mean, you can definitely have e.g. an

    std::variant
Which is a sum of those three types.

Re: C++26: Std:Is_within_lifetime

#65

Post by maleldil »

sebtron wrote: post #64
maleldil wrote: post #62

Earlier quoted context omitted.

These are not proper sum types, since you're limited to one variant per type.

I am not sure what you mean, you can definitely have e.g. an std::variant Which is a sum of those three types.

See the first IpAddr example here[1], where you have separate variants, both with string representations. You can't do this with std::variant. You have to use separate types.

[1] https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

Re: C++26: Std:Is_within_lifetime

#66

Post by chongli »

PaulDavisThe1st wrote: post #45
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.

This particular feature impacts only compiler writers, unless you choose to use it. You can write C++ till the end of time and never use std::is_within_lifetime and it will have zero impact on you or your code. If it gets used in stdlib, there's presumably a reason, and if there isn't, then that's worth criticizing. But adding the feature has no impact on 99% or more of all developers.

That’s assuming a developer owns all the codebases they work on. Many don’t, because they work for an employer with a large team and a large existing codebase. If the language evolves and the project manager is 100% keen on adopting new features then it’s going to affect everyone on the team.

Re: C++26: Std:Is_within_lifetime

#67

Post by PaulDavisThe1st »

chongli wrote: post #66
PaulDavisThe1st wrote: post #45

Earlier quoted context omitted.

This particular feature impacts only compiler writers, unless you choose to use it. You can write C++ till the end of time and never use std::is_within_lifetime and it will have zero impact on you or your code. If it gets used in stdlib, there's presumably a reason, and if there isn't, then that's worth criticizing. But adding the feature has no impact on 99% or more of all developers.

That’s assuming a developer owns all the codebases they work on. Many don’t, because they work for an employer with a large team and a large existing codebase. If the language evolves and the project manager is 100% keen on adopting new features then it’s going to affect everyone on the team.

s/developer/development team/

Re: C++26: Std:Is_within_lifetime

#68

Post by sebtron »

maleldil wrote: post #65
sebtron wrote: post #64

Earlier quoted context omitted.

I am not sure what you mean, you can definitely have e.g. an std::variant Which is a sum of those three types.

See the first IpAddr example here[1], where you have separate variants, both with string representations. You can't do this with std::variant. You have to use separate types. [1] https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

I see what you mean now, thanks. To reproduce that example with std::variant I would need some kind of strong type alias, which as far as I know is missing from C++; so the only feasible way to do that would be wrapping the string in another class or struct.

Re: C++26: Std:Is_within_lifetime

#69

Post by bestouff »

pjmlp wrote: post #32
raincole wrote: post #14

Earlier quoted context omitted.

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…

> Now everyone is doing > > AI tooling => C Source code => Tradicional UNIX C compiler => ASM => object file

Certainly not. I'm using AI to write Rust, the compiler is way better at telling the AI it goofed completely, and the resulting code (once the AI managed to get rid of errors/warnings) has a much better chance of actually working well.

Re: C++26: Std:Is_within_lifetime

#70

Post by ethin »

tialaramex wrote: post #39
ethin wrote: post #27

Earlier quoted context omitted.

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

These concerns seem like OS level concerns. Networking primitives like IP addresses is probably a good idea. But anything more than that (like the GP is implying) is absurd to want in the stdlib.
Post reply on HN