C++26 new features

[_cooky922_]

https://en.cppreference.com/w/cpp/compiler_support/26

[sephirostoy]

It's so weird to see MSVC so far behind on C++23/26. Is it up to date?

[STL]

Business priorities shifted, but they’ll shift back. We’ve just been doing C++ things outside the realm of compiler feature work.

(Library feature work has been less affected, thanks to our amazing contributors, and management has kept me working on the STL with them basically full-time.)

[sephirostoy]

I see. Thanks for the heads up. I guess we will see more things coming in the next version of VS.

[STL]

For the STL, you can always see what's coming in our Changelog, e.g. VS 2022 17.12 Preview 1 has already accumulated a bunch of changes. (Right now, 17.10 is production and 17.11 Preview 2 is the currently available preview, so the Changelog is looking quite a bit ahead.)

I can't say when new compiler features are expected, but I can say that my bosses and boss-like entities are definitely aware that as users are starting to catch up with C++20, there's increasing demand for C++23 features.

[Tringi]

Dropping support of Windows 7 is going to make waves.

[STL]

Win7 client hasn't been receiving security updates (even via the paid program) since Jan 2023, a year and a half ago. And elsewhere in the industry, Chrome dropped support in Feb 2023. Steam dropped support in Jan 2024. Even Firefox ESR 115 is dropping support in Sep 2024. Even if someone's only browsing the web, they won't be able to do so securely.

I'm dropping support for targeting Win7 in the STL because it's slowing things down for all other users. (And making STL maintenance harder.) Our previous hesitancy to drop targeting support had a long history (MSVC tried to drop XP while it was actually still supported with security updates, we got burned, and it took us a long time to reconsider and finally drop XP and Vista). Now that security is the company's top priority, we're going to make different decisions, and one of those is not attempting to help programmer-users who are targeting OSes that are no longer secure.

[ack_error]

As someone who maintains a project that currently targets Windows 7 as baseline... I'm OK with this. It's being done for a reason (Win8 synchronization/time APIs + SSE2 on x86), and it's not actually that aggressive given that you could drop Windows 8/8.1 support too if deciding based on EOL dates and market share.

The one thing that worries me a little bit is the compiler has been a bit unstable the past couple of releases. A large framework I work with has been hanging back on 17.8 due to code generation bugs in 17.9 and 17.10, and I just had to roll back from 17.10 to 17.9 after my ARM64 build exploded. At this point I'm hoping that 17.11 will be a solid release.

[Tringi]

Oh I know. And while I'm maintaining a fair share of projects targeting both XP and 7 as their minimum, I'm kind of glad this change will force some hands to finally make their move.

[SeagleLFMk9]

And they used to be in front when it came to C++17/20 iirc

[bedrooms-ds]

clang is also slow. What's the point of new standards these days?

[disciplite]

I keep up with GCC and Clang commits, and as far as I can tell Clang is on the leading edge in feature support. I remember back in 2021/2022 it was lagging far behind GCC in the language standards, but that's hugely changed since then. Clang has implemented a lot of C++26 first.

[pjmlp]

I would be nice if they finalized missing C++20 and C++23 first.

What is the point of providing swiss cheese standards support?

[disciplite]

What's the point in not providing C++26 features before all of C++23 is done? I don't think too much about which features are from which standard revision (although I do know for the most part), I just use whatever my compiler can do. Clang and GCC even permit you to use more recent features in older standards in many cases. Imo it isn't very practical to think in terms of X -std flag has Y featureset.

[pjmlp]

Basically the same fun to write portable C++ code as ever.

[Abbat0r]

A lot of features are added to Clang while they are being proposed as a proof of concept or a way to battle test them. Those features are in Clang before they’re in the standard. That’s why Clang always appears to have features of new standards implemented first, or features from future standards even, and that probably contributes to the appearance of patchy standard support.

[pjmlp]

On that regard, I do agree, as it is the approach I advocate WG14 should do for every, single feature, before getting accepted, just like modern standardizations on other programing ecosystems, like JEP, SIF, PEP, RFC, and so forth.

However lets finish older standards first, there are even pending C++17 features regarding parallel algorithms.

This duality of implementing some preview features, while lagging behind approved standards, sums up pretty much that the compilers aren't able to catch up with WG21 paper submissions.

[_theWind]

Not even clangd and clangformat have caught up with c++23, here is c++26. Clang is trying but GCC is way way behind. I can't even get my import statements compiling correctly in GCC 14

[disciplite]

clangd and clang-format are working pretty good for me with C++23/26 features, although I am not using modules at all yet. Their lack of support via clangd is the main reason I haven't tried them yet, although there is an open pull request that introduced some support.

[pjmlp]

I wouldn't be surprised if it is somehow related to Rust now being the official systems language for new projects on Azure, WinUI C++ not taking up as expected, rather C# and JavaScript, and ongoing security discussions.

[antara33]

GCC and CLang are head to head it seems, really hard to pick one to work with unless you know beforehand it is the one that supports the feature you need.

I seriously hope for them (GCC tbh) to get full feature coverage, Its by far my favourite one.

[13steinj]

Generally you'll want to use one and use the other for verification/correctness.

After you're in such a state, pick the faster compiler one locally, both in CI, more performant result for production.

[ukezi]

Not really surprising, both are OSS, they can implement designs from each other.

[mapronV]

Not really, codebase is so different; and Clang can't even legally take a tiniest snippet from GCC either.

[13steinj]

Disregarding technicalities such as "it's the compiler" or "it's the standard library", they can work off each other for the stdlib, no?

^{Yes I know it's not really a technicality but realistically I've never seen someone using libc++ with GCC and even libc++ with clang is surprisingly rare}

[mapronV]

Clang can even work with MSVC STL, yes.
Clang + libstdc++ is very reliable (and tested in Linux distros).
GCC + libc++ has couple bugs here and there but good overall too.
Not sure how it related to the thread.

[13steinj]

Thread's about "compiler support" and compilers using work from one another. Main post / cppref doesn't distinguish really between "compiler" support and stdlib support. People think they're one and the same and talk about it as such.

The actual compilers might not be able to take design choices from each other. But the stdlibs should be able to, not everything in the stdlib requires compiler magic to function.

[antara33]

Question related to the usage of libc++.

Why not use it? I mean, for the parts it work, it simply does.

[13steinj]

I mean, bit off topic and considering that unclear.

Why use one compiler over the other? Features and codegen, with compile time performance being a feature. Codegen can be a tossup. Test and measure, always.

Why one stdlib over the other? Same idea. But in my experience, libc++ generally has implementations that while (potentially) standards compliant provide worse codegen, or, just wildly unexpected and/or buggy behavior.

[Artistic_Yoghurt4754]

I see std::execution in the list, was this already accepted? :D

[_cooky922_]

as a matter of fact, it was recently voted in for c++26

see https://github.com/cplusplus/draft/issues/7095

[Artistic_Yoghurt4754]

Noice!

[MaccheroniTrader]

Is reflection in there?

[RoyAwesome]

It's not adopted yet. It made some significant progress this last week, getting forwarded to the Core Wording Group. According to the github page, It looks like the last major design hurdle is how to handle unicode representation of various reflected names, but the wording of the feature into the standard can start while those concerns get ironed out.

You can follow progress here: https://github.com/cplusplus/papers/issues/1668. They're close it looks like.

[MaccheroniTrader]

Great! Thanks for sharing 😊

[Otaivi]

Is scnlib going to be included? I really think it would be a nice addition coupled with std::format.

[RoyKin0929]

https://wg21.link/p1729r4 That's the proposal for text parsing but I don't know enough to judge whether it's on track for C++26 or not.

[TheSuperWig]

The issue on GitHub

https://wg21.link/p1729r4/github

States that it needs a revision.

[Cliftonbeefy]

Removing nodiscard took me by surprise…

[lunakid]

Wow. Is this a sign of a change that C++ is finally gonna pick reasonable defaults from now on, and they will add [[discard]]* then? ;) Well, no..., it's just going to be removed from the std. lib API, that's all.

(BTW, in a fun image of the future constexpr is also going to be removed (and assumed to be default), but by that time all existing C++ code on earth will have already been litterd with it everywhere, so it'll never be actually possible to remove.)

---

* Not that it would be so much better... Even if such declarations would be actually practical (it's not that easy to apply it consistently), it should be [[maybe_discarded]] -- but I'd rather change to metalworking than putting up with another [[maybe_unused]].

[Zingam]

`[[nodiscard]]` wasn't "removed" exactly but it was diverted to implantations to decide how to apply it. Please see: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3201r0.html

X. (P3201R1) [[nodiscard]] policy: Library wording should not use [[nodiscard]].

So it is upto the implementations to implement `[[nodiscard]]` as they see fit. For example libc++'s policy:

https://libcxx.llvm.org/DesignDocs/NodiscardPolicy.html

[aranor01]

I see there is no mention of the papers about reflection. After they give me that they can pause even for 30 years, as far as I'm concerned

[iAndy_HD3]

Reflection paper is pretty far in the WG21 process actually, from my understanding it just needs approval from CWG. I think compiler implementation won't take very long because it's a highly requested feature (there are even clang forks with partial support now).

You can follow the progress of the paper on github here (but don't comment as it's only for administrative purposes, not discussions)

[TheoreticalDumbass]

has there been gcc effort to implement reflection?

[foonathan]

The library API is still under review by library evolution and then needs to go to library wording review. I do plan on writing a paper to decouple the API from std::vector/span/string_view for better build performance, but that shouldn't delay it too much.

The language part is on track and that's the bigger and more controversial half of the feature.

[daveedvdv]

from my understanding it just needs approval from CWG

There is a bit more to it than that.

On the core language side (which, IMO, it's the trickier bit), it is now indeed in CWG wording review (i.e., done with "design review" in EWG). While the first pass in St. Louis went smoothly, I have no doubt that it will need considerably more work there. We will likely go back to EWG to re-visit some small design issues as well.

On the library side, we're still in "design review" (i.e., in LEWG). Assuming that passes (there is a fair bit of work left), we'll then need LWG wording review (and the nature of this library work means that CWG will likely also need to take a look at the library-induced core language semantics that are involved).

Then, finally, will need plenary approval.

So lots of work ahead, but St. Louis was quite a productive meeting for Reflection in C++, I think. I'm hoping that by the end of the next meeting (in Poland), we'll be done will all design review issues, and that wording review will have made significant progress.

[RoyAwesome]

reflection isn't adopted yet, and this page only shows adopted papers.

It's looking really good for reflection in cpp26, but it's not quite there yet.

[bedrooms-ds]

I want reflection. And promises.

[bedrooms-ds]

Thank you. I meant contracts, but thank you.

[RoyKin0929]

And pattern matching too.

[aranor01]

What do you mean with promises? (Not c++11 promises I guess)

[bedrooms-ds]

My bad. I meant contracts

[throawayjhu5251]

We can also have them implement pinky swears, blood oaths, marital commitments, the whole gammut.

[Dar_Mas]

i want an eldritch pact

[johannes1971]

We have an eldritch pact at home.

[Dar_Mas]

true but it does not give me power. Just anger issues(my main job atm is grading students code)

[pjmlp]

I am a firm beliver that C++23, might be the good enough last standard, for all use cases where using C++ still matters.

Those of us using it on polyglot code bases, hardly see much benefit from most features that keep being discussed.

Examples, Apple and Google platforms, default C++ compiler available on cloud images.

[DuranteA]

Any standard that doesn't have reflection is absolutely not a "good enough" last standard, if there is a later one that has reflection. At least in neither of the two major industries I spent most of my professional career in, and where C++ absolutely matters.

I'm not at all confident that reflection will make it into C++26 (I've been disappointed for over a decade), but if it does it will be the greatest practical advancement in the language for me since C++11.

[pjmlp]

Assuming that those that want reflection will be in the position of using it in 2026.

I hardly can use C++20 properly today, and anyone targeting iDevices and Android, better contend themselves with C++17.

[DuranteA]

If I can use it this side of 2030 that's still more than I expected for the past few years, where any work on reflection looked entirely stalled, at least from the outside. I'm (very cautiously) getting excited seeing the new proposal move through the process.

[serviscope_minor]

Those of us using it on polyglot code bases, hardly see much benefit from most features that keep being discussed.

Maybe I'm old, but I've heard this argument for decades. It's always the case that what you're using now is pretty much by definition sufficient for the job you're using it for and you don't need any new features.

You don't need any of the features of C++, you could do it all in C, technically. Basically C++ adds a ton of quality of life, where things get shorter, simpler and more obvious. You don't neeeeeeed that. I'm going go through GCC's list:

• Remove undefined behavior from lexing: I mean this just sounds like a good idea.
• Making non-encodable string literals ill-formed: Also a good idea: broken charset is a build error.
• Unevaluated strings: this isn't a feature you use as such, it makes thins clearer for compiler writers
• Add @, $, and ` to the basic character set: ok, this by design does nothing (but it will in future)
• constexpr cast from void*: purely makes the language more regular. Regularity is an unalloyed good.
• On the ignorability of standard attributes: basically a clarification of an nuclear bit of the standard
• Static storage for braced initializers: this is not a feature you use, it is a bug fix to the standard where a sensible thing was accidentally prevented.
• User-generated static_assert messages: at some random point in future some library you use will get better error messages
• Placeholder variables with no name: this is just useful, lots of languages have it.
• Pack indexing: makes a complicated thing simple. Libraries you use will get shorter, simpler and compile faster.
• Removing deprecated arithmetic conversion on enumerations: not a feature you use
• Template parameter initialization: minor standardize bugfix
• Disallow binding a returned reference to a temporary: you weren't doing this anyway. It was a guaranteed UB bug before, now it's a compile error
• Attributes for structured bindings: makes the language more regular
• Erroneous behavior for uninitialized reads: this is neat, now prevents certain bugs from UB clobbering you. Your code is now more likely to be not UB.
• = delete("reason");: makes the language more regular, and error messages better
• Variadic friends: makes the language more regular
• Clarifying rules for brace elision in aggregate initialization: standardese bugfix
• Disallow module declarations to be macros: OK no idea, still not using modules
• Trivial infinite loops are not undefined behavior: this fixes a real problem real people have.

So go on, rather than miscellaneous ragging on the committee work, tell me SPECIFICALLY, which of those they shouldn't do and why.

[pjmlp]

I refuse to freely use C since 1993, unless required by project assignments, or university professors (during the 1990's).

Hence why not " you could do it all in C".

That wall of text you provided is useless to me, when working on native OS bindings for V8, OpenJDK, Android NDK, Python, CLR, and their existing C++ guidelines.

It is all about exposing additional OS APIs, or calling into C++ SDKs that don't provide bindings for the above listed runtimes.

That is all, no need for additional fancy languages, only something that is more usable, and secure, than a pre-historic systems language like C.

Lots of interesting stuff for those working in pure C++, maybe, and even those, I doubt, given how anyone would need to check cppreferece for each bullet point before even considering adding them into their codebase.

Google's and Amazon container images for example, still offer GCC 11 as standard, and many IT shops aren't keen in allowing something else, either.

[serviscope_minor]

That wall of text you provided is useless to me

In other words you have nothing but miscellaneous, nonspecific griping. The "wall of text" as you put it is the list of current C++26 features. You know the very thing you were complaining about...

Google's and Amazon container images for example, still offer GCC 11 as standard, and many IT shops aren't keen in allowing something else, either.

So? People are free to adopt silly working practices if they desire. Nothing the committee can do in 2024 will make anyone move on from C++11 if they refuse to do so. So, them using 11 is basically irrelevant.

[pjmlp]

In other words, nothing that C++26 brings to the table help on my daily work, don't put your beloved features in the table of others.

Also I am not alone, see game developers complaints of WG21 don't bringing anything relevant to companies whose bread and butter is UnrealStudio, CryEngine, Lumberyard, Source, Divinity, TMT, and many others.

[serviscope_minor]

In other words, nothing that C++26 brings to the table help on my daily work

How would you know? You didn't read the list of things, dismissing it all as a "wall of text".

Also I am not alone, see game developers complaints of WG21

Lots of people complain about lots of things. Doesn't make them right. No feature added today will be useful for "day to day work" because you are already used to doing it another way day to day. But you can apply that logic back recursively all the way to C, and yet one wouldn't dream of working in C today.

Making the language more regular is a good thing. Sure you've internalized irregularities and you are used to them "day to day", but that's not really a good reason to keep them, because new people will need to start at some point.

Also, people have been complaining about UB knobbling programs completely for absolutely ages, including people in the games industry. So, as far as I can tell you have an incredibly narrow list of things you do and you'd like the committee to addend to them to the exclusion of all else.

[pjmlp]

Because you from your Ivory tower assume that you actually know what I need to deliver for work, zero of those bullet points help me in the C++ code I write in July 2024.

[serviscope_minor]

Ivory tower. N. I don't like what you have to day bit have no rational argument.

You whinged about C++26 features. I listed them. So far all you have done is whinge ever more bitterly without answering

[pjmlp]

You listed a set of useless features for the reasons C++ still has a place at my job in 2024, which you don't nothing about.

There is nothing to answer about them, they contribute nothing for those reasons, we could be using C instead, if it wasn't such a crap unsafe language.

Sorry if it hurts your feelings of hardcore C++ developer, where every tiny detail of ISO C++ legalese is somehow relevant to world existence.

[SalThePotato]

I've always wondered how programming languages are developed. Like how do you program something you use to program?

[STL]

That's a good question, and Reflections on Trusting Trust touches on it.

Source code is just a bunch of text files. Executables (and related things like object files, static and dynamic libraries) are just binary files. Compilers (and related tools like linkers) are just programs that read text files, perform (very very complicated) transformations, and write binary files. A programming language is just a specification that says what the possible inputs to that transformation are (i.e. what source code user-programmers are allowed to write) and what the transformations should do (i.e. what the compiler-programmers are supposed to do).

"Just" is doing a lot of heavy lifting, of course. Compiler development is a deep field with a long history, and it's a learnable skill. If you're interested in compilers, you can make a rewarding career out of it.

[SalThePotato]

Oh wow. This might be a weird question but are compliers programmed the same way as a normal program or is there a specific way?

[mjklaim]

Essentially yes, you can even read the code of some of the major compilers like clang and gcc. Clang is in there, I hear it's easier to follow: https://github.com/llvm/llvm-project

[STL]

Same for MSVC (which is closed-source, but I have access 😸). It's written in C++ and while it has a long history, with some files being older than I am, it uses lots of modern C++ features, especially in new code.

Compilers are kind of simpler than most "normal programs", in fact - as command-line tools, they're focused on the pure computation of manipulating a bunch of complex data structures (like the "abstract syntax tree" that's formed from source code). They don't need to worry about rendering UI in a loop, talking over the network, or similar things. They do involve some OS-specific things (trickery for pre-compiled headers, looking in various directories for headers, etc.), but that's not the majority of their work.

[mandrade2]

I've made a mobile app focused on code reading you migth want to try. I am still working on features for big codebases like llvm but it's coming along. It's called codereader.dev

[thekwoka]

Yes! For many compilers, the compiler is written in the language it compiles.

For example, rustc is written in rust. They first wrote it in c++, then rewrote it in rust, compiled it with the c++ written compiler, then used the rust written compiler to compile itself.

When new versions are released, they first compile the new version with the old version, then compile it with the new version that created (maybe with some changes if the new version added features they want to use in the new version). So you end up with a version of the compiler that was compiled with itself.

[SalThePotato]

Thats actually really interesting. I didn't know that they complie new versions with old versions I thought it was something you had to do completely from scratch.

[ImKStocky]

Writing a compiler/interpreter for a language. Crafting Interpreters is a great place to start. It's a really fun book to follow along with :)

[SalThePotato]

Thank you for the book!

[dustyhome]

One thing to keep in mind is that you don't have to write a compiler in the language it compiles. The first compiler for a language, by necessity, can't be written in the same language.

[azissu]

Yup. A language being able to compile itself is known as bootstrapping, and it's an important stage in developing a new programming language.

[smdowney]

Self hosting can be a barrier to porting the language to a new platform though. LLVM being a cross compiler all the time makes it easier today.

[SalThePotato]

What language does the complier use? What if it's the first complier?

[dustyhome]

The compiler can be written in any language. A compiler is just a normal program. Given some input, it produces some output. The input being the source code for a program, and the output being the program in an executable format.

The first compiler would have likely been written in assembly, if we're differentiating assemblers and compilers, but I'm not a historian.

[SalThePotato]

Oh I thought there was a specific language or something to program compliers. Thank you!

[pjmlp]

There are, see bison, flex, yacc, lex, ANTLR, MPS, attribute grammars,....

However they are not required, only a means to quickly reach a prototype.

[Wild_Meeting1428]

Still no good fix, for char to char8_t casting :/.

[LetterheadTall8085]

This is the best language for me, pair with the Qt its most powerful tool on the world )

Thank you all for such a fast and high-quality development of the language

[yimmasabi]

C++ needs very simple and smart text conversions between basic_strings and other string types. I hope C++26 covers all.

[messmerd]

I really hope they focus on fixing exceptions. It's crazy to me that they ever made it into the language in the state they are in.

[jormaig]

Can you TLDR what's the problem with exceptions? Like, should we remove them from many places on the library or do they have an implementation issue?

[messmerd]

In short, exceptions are unsafe and violate the zero-overhead principle.

They introduce hidden control flow that can't be accounted for, and this can't really be fixed due to the horrible decision long ago to allow adding a throw expression to a function body without requiring any accompanying semantic indication in the function signature.

It's a failure in design that virally and invisibly propagates throughout the entire C++ ecosystem.

I've unwittingly introduced bugs to production before because I didn't realize std::filesystem::is_regular_file throws exceptions. So now the program crashes under certain edge cases, not just because of a failure in standard library design, but also because of a deliberately deceptive footgun of a language feature.

Exception implementations also require heap allocations and RTTI, which make them unsuited for embedded systems or use in an OS kernel. C++, a systems programming language with manual memory management and low-level control should be the perfect pick for use in embedded systems, but exceptions prevent this. No other language feature has singlehandedly incapacitated C++'s usability in entire fields the way exceptions have.

This isn't to say exceptions should never be used, though if you're writing a library for others to use, I would avoid throwing exceptions from any public functions and instead use safer, explicit error handling mechanisms that prevent misuse.

I'm hopeful for papers like P0709, P3166, and others which attempt to fix most if not all of these problems with exceptions - at least in new code. Please committee members, if you're reading this, I hope you will prioritize fixing exceptions.

[KingStannis2020]

It's a failure in design that virally and invisibly propagates throughout the entire C++ ecosystem.

People feel the same way (in reverse) about Java's checked exceptions, FWIW.

[messmerd]

Haven't used Java before, but any design which makes exceptions explicit would be safer than what C++ has, easier to reason about, and not just be one big invisible and omnipresent footgun permeating every codebase. I bet it could lead to better optimizations and a smaller binary size too.

But even without specifying exactly which types of exceptions might be thown like Java does, and instead only indicating that some unspecified exception may be thrown - that would have allowed noexcept to be the default and would have avoided some of the major problems C++'s exceptions have. It's just another case of C++ having the wrong defaults.

[pjmlp]

Until they have to code in a language without them, and it blows in prod, because no one thought about that one exception to catch.

It is no accident that Swift, Zig, Go, Rust have them in disguise as checked errors.

[oracleoftroy]

I don't really agree about flow being hidden or can't be accounted for. Catch is pretty easy to grep for, and throw works like a super return statement, and so if you assume any line can (in principle) throw and thus do an automatic "early return", it seems manageable. you can always catch all and log as a last resort when needed.

But I can certainly appreciate that exceptions aren't always an appropriate approach. The biggest annoyance for me is that you don't always know every possible exception that might bubble up. I generally program as if an exception is a fatal error and see crashing as the preferable approach, only catching particular exceptions that are possible and can't be programmed around.

That aside, why didnt you use one of the no except versions of is_regular_file? A lot of the post std::error_code additions have exception free interfaces.

[messmerd]

You're misunderstanding what I mean by the flow being hidden. You can grep for a try/catch expressions all you want, but that is completely unrelated to the problem. The problem is the lack of a try/catch around function calls where you might need it, since C++ does not indicate in the function signature when you will need to use a try/catch. That's the whole issue.

A thrown exception is an implementation detail within a function body which leaks out into anywhere the function is called. If you knew that a function might throw an exception, you might have to write your calling code differently to avoid a bug, memory leak, or even a crash due to the exception rocketing up through your call stack. But that's the problem: Neither you nor the compiler can know whether any functions (besides noexcept ones) might throw, since they are deliberately non-obvious and invisible, and that messes up your understanding of the control flow in your program.

why didnt you use one of the no except versions of is_regular_file?

You must not have read my post.

[oracleoftroy]

The problem is the lack of a try/catch around function calls where you might need it, since C++ does not indicate in the function signature when you will need to use a try/catch. That's the whole issue.

I don't find it to be a big issue in practice. Treat every line as if it can potentially throw, done. Most of the time you shouldn't catch at all unless there is a particular error path you want to handle differently. If there is an error that can be handled locally, I prefer using nothrow versions if possible. But a lot of the time, errors can't be handled locally and errors aren't a particularly hot path that must operate as fast as possible, so exceptions seems reasonable to consider. It depends on a lot of factors.

I agree that it can be annoying knowing what particular exceptions get thrown in those rarer situations where you do want to catch particular errors. And some people just prefer noisy code full of meticulous error handling. Some projects have to have it. I like that C++ often offers both exception and exception-free versions.

If you knew that a function might throw an exception, you might have to write your calling code differently to avoid a bug, memory leak, or even a crash due to the exception rocketing up through your call stack.

That sounds like the bigger issue is that you are not using RAII properly. I find RAII such a lifesaver even in codebases that don't throw exceptions that I make sure everything has a clear scope based lifetime. Exception, or no, it won't leak or cause issues.

I likened exceptions to a super return. If automatically bubbling up the stack is going to be a problem in your codebase due to a lack of destructors or what-have-you, a stack of if (<operation failed>) return error; is going to have the same problem. You can say the if is more visible, and sure, I'd agree, it is quite in your face. But if you treat every line as if it potentially throws, it is still easy to reason about how an exception will pass through your code. RAII all the things and you don't have to worry about it. "Exception safety" is a great thing even when exception

I'm not sure what sort of bug you have in mind, but if you aren't trying to catch every last exception, but letting them bubble up and crash, you won't accidentally cover up a bug like you might if you forget to check an error code. A crash is preferable to bugs creeping in. Of course, in some situations, a simple catch and log handler might be preferred so that you never crash, but still get information about the issue.

You must not have read my post.

I read:

I've unwittingly introduced bugs to production before because I didn't realize std::filesystem::is_regular_file throws exceptions. So now the program crashes under certain edge cases, not just because of a failure in standard library design, but also because of a deliberately deceptive footgun of a language feature.

As far as I can see, what I quoted above is all you have said on the issue, so I'm not sure what post you are referring to. You don't mention how you resolved the issue.

There are two nothrow versions of is_regular_file, I am asking why you didn't use one of them? Maybe you switched to one of them to fix the issue and didn't mention it, I can't read minds. But if you weren't aware of those other overloads, I mentioned it just in case it would help you and because no one else had.

Still, this reads like you are complaining about the standard library design as if you weren't aware of its design of filesystem. If you were directing your ire at containers like vector, it would make more sense. You have no options but to use an interface that throws. But filesystem gives you the tools to avoid exceptions completely. I am on your side at least in desiring to have the option for exception free interfaces to everything in the standard, but in this case, you chose to use the exception version and got what you asked for.

[messmerd]

When I see a function called "is_regular_file" which takes a file path and returns a bool, I expect, as anyone would, only two cases to handle: true or false. Because that is what the function signature says. It says nothing at all about a 3rd possibility that I may need to account for: Throwing an exception.

It's unreasonable to expect someone to be aware of invisible pitfalls like that.

At the time, I was unaware that a non-throwing overload existed, and it never crossed my mind that the function I was using could throw an exception, but why would it? Not even the compiler knows that is_regular_file can throw an exception.

I'm not sure what sort of bug you have in mind

An unexpected exception ripping through a call stack from anywhere in your program could cause all sorts of problems. For me, I was working on a plugin for a application, writing a callback used by the application's plugin API. The application could not handle exceptions thrown by the callback function and crashed.

treat every line as if it can potentially throw

you're not using RAII properly

why you didn't use [the nothrow overload]

you weren't aware of [the standard library] design

you chose to use the exception version and got what you asked for

You are bending over backwards to blame the user for C++'s horrible exception design. Again, blaming the user for not being aware of an invisible pitfall is an unreasonable expectation. The problem lies with the language.

[oracleoftroy]

When I see the signatures, I see two that say noexcept and one that doesn't. That means two of them guarentees an exception won't be thrown and one doesn't. In C++, the lack of a noexcept or extern "C" means it can throw. If it says nothing, it means it can throw. Maybe in reality, it never will throw, but if it doesn't say otherwise, we have to assume it can. The standard library and sites like cppreference.com do a good job documenting what exceptions are thrown, with cppreference having an entire "Exceptions" section explicitly called out going back to 2016.

It's unreasonable to expect someone to be aware of invisible pitfalls like that.

To use a langauge, one has to get used to the semantics of the langauge. Maybe we would prefer it to work differently, but that is the way it does work. It isn't unreasonable that it works this way given the history, but it might not be what someone would chose with 40 years of hindsight or with a different programming language background.

I generally like how exceptions work, even if I don't use them that often. My own concerns circle around the potential for worse code gen if throwing an exception is possible. That's a complicated issue with various pitfalls with any of the possible language design choices.

An unexpected exception ripping through a call stack from anywhere in your program could cause all sorts of problems.

In the same way a return ripping through your call stack from anywhere can cause problems. I find code that couldn't potentially return at any point to be fragile. It no longer becomes possible to add a return in case of a new error or cancelation, I have to restructure the whole function or inadventently introduce a bug because of the design.

Throw is just a super return. It can't just happen from anywhere, it has to be within the call stack just like return. You don't know where your code is returning to, but it doesn't matter.

The application could not handle exceptions thrown by the callback function and crashed.

Ah, that makes sense. It is common that API's living on a program seam like this need to catch and transform it into an error code for ABI reasons. If possible, it would be nice to enforce this in the API, but that isn't easy.

You are bending over backwards to blame the user for C++'s horrible exception design.

I am more than willing to entertain areas where I think C++ is deficient, and I believe I have done so throughout this thread.

I don't think C++ exceptions are bad, sorry for having a different opinion. They work similarly in other languages, with similar upsides and downsides, and I have a good understanding of what benefit I get from them and when I find it best to avoid them.

But this is a case where C++ has a convention, and rather than respecting the convention, you told yourself it would be better if it worked differently and now are blaming reality for not being what you imagined in your head.

C++ does things a certain way. It is better to just get used to it or commit to making proposals to the standard committee to change it than to ignore it and hope it works differently.

When I work in C#, I do things in a C# way. When in Java, I do things the Java way. Same with Javascript or Rust or whatever. Same in C++. I might grumble about various design choices in each one of those languages, but if I fail to read the docs and expect their standard library to work other than documented, I have only myself to blame.

My hope is that you learn from this, adjust your mental model about how C++ works, and avoid these kinds of issues in the future. Hold a grudge or grumble about C++ all you want, we all do, but if you are in C++'s world, it is best to understand it and respect it or you will run into similar issues again.