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

C++26 is done: ISO C++ standards meeting Trip Report

herbsutter.com

Post reply on HN
Print view View original

331–340 of 437 posts

Re: C++26 is done: ISO C++ standards meeting Trip Report

#331

Post by aw1621107 »

jandrewrogers wrote: post #327
affenape wrote: post #6

Finally, reflection has arrived, five years after I last touched a line in c++. I wonder how long would it take the committee, if ever, to introduce destructing move.

C++26 adds destructive moves. They are called relocatable types. There are edge cases where destructive moves are not safe and it is impossible for the compiler to know they aren't safe. C++ uses non-destructive moves when it can't prove the safety of destructive moves, even if destructive moves may in fact be safe. C++26 adds a type annotation that guarantees destructive moves are safe in cases where you can't prove…

> C++26 adds destructive moves. They are called relocatable types.

I thought those were removed? For example, see Herb's 2025-11/Kona trip report [0]:

> For trivial relocatability, we found a showstopper bug that the group decided could not be fixed in time for C++26, so the strong consensus was to remove this feature from C++26.

[0]: https://herbsutter.com/2025/11/10/trip-report-november-2025-...

Re: C++26 is done: ISO C++ standards meeting Trip Report

#332

Post by aw1621107 »

germandiago wrote: post #295
sidkshatriya wrote: post #270

Earlier quoted context omitted.

One of the biggest knocks against Rust as a systems programming language is that it has weak compile-time and metaprogramming capabilities compared to Zig and C++ In the space of language design, everything "more powerful" is not necessary good. Sometimes less power is better because it leads to more optimisable code, less implementation complexity, less abstraction, better LSP support. TL;DR More flexibility and com…

But compile-time processing is certainly useful in a performance-oriented language. And not only for performance but also for thread safety (eliminates initialization races, for example, for non-trivial objects). Rust is just less powerful. For example you cannot design something that comes evwn close to expression templates libraries.

> For example you cannot design something that comes evwn close to expression templates libraries.

You keep saying this and it's still wrong. Rust is quite capable of expression templates, as its iterator adapters prove. What it isn't capable of (yet) is specialization, which is an orthogonal feature.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#333

Post by Twey »

ozgrakkurt wrote: post #329
tialaramex wrote: post #243

Earlier quoted context omitted.

RPIT (Return Position impl Trait) is Rust's spelling of existential types. That is, the compiler knows what we return (it has certain properties) but we didn't name it (we won't tell you what exactly it is), this can be for two reasons: 1. We didn't want to give the thing we're returning a name, it does have one, but we want that to be an implementation detail. In comparison the Rust stdlib's iterator functions all r…

Like you said it is possible to not use this feature and it arguably creates better code. It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object. A lambda is essentially a struct with a method so it is the same. I understand about auto trait impl and agree but it is still annoying to me

> It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object.

IMO it is a hack to use dynamic dispatch (a runtime behaviour with honestly quite limited use cases, like plugin functionality) to get existential types (a type system feature). If you are okay with parametric polymorphism/generics (universal types) you should also be okay with RPIT (existential types), which is the same semantic feature with a different syntax, e.g. you can get the same effect by CPS-encoding except that the syntax makes it untenable.

Because dynamic dispatch is a runtime behaviour it inherits a bunch of limitations that aren't inherent to existential types, a.k.a. Rust's ‘`dyn` safety’ requirements. For example, you can't have (abstract) associated types or functions associated with the type that don't take a magic ‘receiver’ pointer that can be used to look up the vtable.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#334

Post by Twey »

WalterBright wrote: post #153
suby wrote: post #11

I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified. Here's a quote from Bjarne, > So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much…

I implemented Contracts in the C++ language in the early 90's as an extension. Nobody wanted it. https://www.digitalmars.com/ctg/contract.html

I think it's also true that, regardless of the desirability of the feature at the time (which sibling comments discuss eloquently) people who've bought into a language are usually quite wary of also buying into extensions to that language. The very act of ratification by the committee gives this proposal a ‘feature’ that the DMC++ extension lacked in compatibility expectations over time and across implementations — it's not necessarily a comment on the technical quality or desirability of the work itself.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#335

Post by ozgrakkurt »

Twey wrote: post #333
ozgrakkurt wrote: post #329

Earlier quoted context omitted.

Like you said it is possible to not use this feature and it arguably creates better code. It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object. A lambda is essentially a struct with a method so it is the same. I understand about auto trait impl and agree but it is still annoying to me

> It is the right tradeoff to write those structs for libraries that absolutely have to avoid dynamic dispatch. In other cases it is better to give a trait object. IMO it is a hack to use dynamic dispatch (a runtime behaviour with honestly quite limited use cases, like plugin functionality) to get existential types (a type system feature). If you are okay with parametric polymorphism/generics (universal types) you sh…

It takes less time to compile and that is a huge upside for me personally. I am also not ok with parametric polymorphism except for containers like hashmap

Re: C++26 is done: ISO C++ standards meeting Trip Report

#336

Post by nickelpro »

daemin wrote: post #203
zarzavat wrote: post #142

Earlier quoted context omitted.

Also, having one standard packaging format and registry doesn't preclude having alternatives for special use cases. There should be a happy path for the majority of C++ use cases so that I can make a package, publish it and consume other people's packages. Anyone who wants to leave that happy path can do so freely at their own risk. The important thing is to get one system blessed as The C++ Package Format by the sta…

That would actually be pretty cool. Though I think there might have been papers written on this a few years ago. Does anyone know of these or have any updates about them?

CPS[1] is where all the effort is currently going for a C++ packaging standard, CMake shipped it in 4.3 and Meson is working on it. Pkgconf maintainer said they have vague plans to support at some point.

There's no current effort to standardize what a package registry is or how build frontends and backends communicate (a la PEP 517/518), though its a constant topic of discussion.

[1]: https://github.com/cps-org/cps

Re: C++26 is done: ISO C++ standards meeting Trip Report

#337

Post by poppadom1982 »

WalterBright wrote: post #154
selfmodruntime wrote: post #108

Earlier quoted context omitted.

In essence, a standard committee thinks like bureaucrats. They have little to no incentive to get rid of cruft and only piling on new stuff is rewarded.

In D, we are implementing editions so features that didn't prove effective can be removed.

Yeah dude but you've really marketed D poorly. I remember looking at D what must be 15 years back or so? And I loved the language and was blown away by its beauty and cool features. But having no FOSS compiler and the looming threat of someone claiming a patent (back then it was unclear that Mono/C# was "legal" and even Java hung in the balance) was too scary for me to touch it.

Now I'm old and I believe D has missed its opportunity. Kinda sad.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#338

Post by estimator7292 »

randusername wrote: post #291
suby wrote: post #11

I am somewhat dismayed that contracts were accepted. It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified. Here's a quote from Bjarne, > So go back about one year, and we could vote about it before it got into the standard, and some of us voted no. Now we have a much…

> It feels like piling on ever more complexity to a language which has already surpassed its complexity budget, and given that the feature comes with its own set of footguns I'm not sure that it is justified. This is a common sentiment about C++, but I find it very interesting that everyone seems to have a different feature in mind when they say it.

I think that's a clear and unambiguous point in favor of the argument. There are so many hellishly complex things in C++ that the community can't settle on even a small subset to be the worst contender.

Half Life 3 rules apply. Every time someone complains about complexity in C++, the committee adds a new overly complex feature. It remains a problem because complexity keeps getting shoveled on top of the already complex language.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#339

Post by nickelpro »

devnullbrain wrote: post #83
AyanamiKaine wrote: post #34

Earlier quoted context omitted.

Can you explain why you think modules are a failed idea? Because not that many use them right now? Personally I use them in new projects using XMake and it just works.

I'm not the PC but I think you miss most of the pain points due to: 'personal' projects. There's not a compatible format between different compilers, or even different versions of the same compiler, or even the same versions of the same compiler with different flags. This seems immediately to create too many permutations of builds for them to be distributable artifacts as we'd use them in other languages. More like a…

BMIs are not considered distributable artifacts and were never designed to be. Same as PCHs and clang-modules which preceded them. Redistribution of interface artifacts was not a design goal of C++ modules, same as redistribution of CPython byte code is not a design goal for Python's module system.

Modules solve the problems of text substitution (headers) as interface description. It's why we call the importable module units "interface units". The goals were to fix all the problems with headers (macro leakage, uncontrolled export semantics, Static Initialization Order Fiasco, etc) and improve build performance.

They succeeded at this rather wonderfully as a design. Implementation proved more difficult but we're almost there.

Re: C++26 is done: ISO C++ standards meeting Trip Report

#340

Post by Conscat »

jesse__ wrote: post #183
jandrewrogers wrote: post #171

Earlier quoted context omitted.

Many of the recent C++ standards have been focused on expanding and cleaning up its powerful compile-time and metaprogramming capabilities, which it initially inherited by accident decades ago. It is difficult to overstate just how important these features are for high-performance and high-reliability systems software. These features greatly expand the kinds of safety guarantees that are possible to automate and the…

> powerful compile-time and metaprogramming capabilities While I agree that, generally, compile time metaprogramming is a tremendously powerful tool, the C++ template metaprogramming implementation is hilariously bad. Why, for example, is printing the source-code text of an enum value so goddamn hard? Why can I not just loop over the members of a class? How would I generate debug vis or serialization code with a norm…

> Why, for example, is printing the source-code text of an enum value so goddamn hard?

Aside from this being trivial in C++26, imo it isn't actually that tricky. Here's a very quick implementation I made awhile ago: https://github.com/Cons-Cat/libCat/blob/3f54e47f0ed182771fce...

Post reply on HN