CppCon 2026 Keynote: C++: Profiles for Simplicity and Guarantees -- Bjarne Stroustrup

[u/VinnieFalco]

https://isocpp.org/blog/2026/09/cppcon-2026-keynote-cpp-profiles-for-simplicity-and-guarantees-bjarne-strou

[u/praesentibus]

Of all the paper tigers, profiles are the most paper tiger there is.

[u/_a4z → u/praesentibus]

Have you ever read the contract papers? Guess not; otherwise, you would know where the top paper exercise happens.

[u/praesentibus → u/_a4z]

“Have you ever read the contract papers?” is always the first question of Contract Witnesses.

[u/_a4z → u/praesentibus]

All of them? Do you even know how many there are :)

[u/throw_cpp_account → u/_a4z]

Had you read the contracts papers, you would have noticed that there are both clearly laid out rules and implementations.

People might not like what those rules actually are, but they definitely exist. Indeed, the fact that they exist is the reason why people can object to them in the first place.

[u/_a4z → u/throw_cpp_account]

I find it interesting and telling that you, and some others, react to my post, but not to the post I commented on.
There is nothing wrong with what I wrote, because there are so many papers on this topic like no other.

Hint: incomplete, since meanwhile we have 5 to 10 more papers, list of contract papers: https://a4z.noexcept.dev/blog/2026/05/20/The-Contract-Papers.html

so, whats wrong on my statement: ... you would know where the top paper exercise happens.

but I guess you, u/kammce and u/praesentibus find it more interesting to rage on keywords than to understand ;-)

[u/Som1Lse → u/_a4z]

so, whats wrong on my statement: ... you would know where the top paper exercise happens.

Paper tiger means something that appears strong and powerful but is actually weak and ineffectual. It does not mean a feature with a lot of papers published about it. Linking to a list of papers about contracts means absolutely nothing.

[u/_a4z → u/Som1Lse]

Thank you, but if you had read what I wrote, and not just reacted to keywords, you would have seen I have used the term `paper exercise`.

But since you mention paper tiger, do you mean work like contracts that are totally unusable for huge parts of the industry? ;-)

[u/Som1Lse → u/_a4z]

Thank you, but if you had read what I wrote, and not just reacted to keywords, you would have seen I have used the term `paper exercise`.

You are the one who misunderstood a term. I pointed out how you misunderstood the term. What's wrong with the statement "you would know where the top paper exercise happens" is that it bears no relation to the comment you replied to, as I pointed out.

But since you mention paper tiger, do you mean work like contracts that are totally unusable for huge parts of the industry? ;-)

Please elaborate. Assertions are hugely useful in general and contracts are basically assertions with better language support. How are they "totally unusable for huge parts of the industry"?

[u/throw_cpp_account → u/Som1Lse]

I like how this guy is going for maximally patronising, to compensate for his lack of... everything. Impressive really.

[u/_a4z → u/Som1Lse]

Sure, thank you for the explanation!

About your question, nobody is using assert in real code, there are frameworks, and contracts will not replace those.
Maybe in 29, when you can have non-ghost code, they might; we will see.
But even then, if double-condition evaluation does not go away and you have guarantees for execution, who shall use it in serious code?
But I am sure you know all about that,

So far

Rust

• assert! debug_assert!

Swift

• precondition, preconditionFailure assert, assertFailure

Simple, more powerful, usable not just as a debug feature;
It also works for analysis.

And we can not compete despite all the papers and committee time spent.
Experts!

And now I am done here; again, I am surprised you and some others react to my post, but not to the offense the person did I commented on. Very telling. And I feel sorry for you and people like you.

[u/Som1Lse → u/_a4z]

About your question, nobody is using assert in real code, there are frameworks, and contracts will not replace those.

People are using assertions, whether they're assert or not. One of those frameworks is bsls_assert which heavily influenced the contracts design. Much like std::shared_ptr people will switch to the standard solution once it's available and suits their needs.

But even then, if double-condition evaluation does not go away [...] who shall use it in serious code?

I don't believe double-condition evaluation is in the current proposal, though I don't personally have huge issues with it. I think I'll manage, if a null or bounds check is performed twice.

Right now it's a souped-up assert that avoids issues with side-effects and doesn't std::abort but instead calls a customisable handler. It's applicable anywhere you'd want an assert and a few places where assert isn't applicable, like when you don't want to terminate in production. It can also appear in signatures to help documenting the function, both for programmers and static analysis tools.

I would certainly appreciate more granular controls, but what's there is useful right now, and the design allows for those granular controls to be added later.

Simple, more powerful,

Are they though? Because Rust's macros panic! or do nothing, Swift's terminate, do nothing, or UB. handle_contract_violation is allowed to throw or observe, so you can keep running the program. (I know you can catch panic!s in Rust.)

And now I am done here; again, I am surprised you and some others react to my post, but not to the offense the person did I commented on. Very telling.

What do you want me to say? First we heard of profiles was in 2023 and we've seen bugger all in the mean time except a bunch of papers. It was spearheaded by some influential people (Bjarne among them), but so far there is no implementation, only papers. I.e., a paper tiger, pun and all.

Could it be that the reason we didn't reply to it was because we didn't find it to be very offensive? To me, whether or not profiles turns out to be a "paper tiger" is up to its proponents to disprove. (Something they very well might. I'm not counting profiles out, I'm just waiting until there's something real I can actually use.)

In comparison, your post clearly missed the point of that post, then your next post doubled down on it, which is all very easy (and very fun) to point out.

[u/throw_cpp_account → u/_a4z]

I'm glad you found my comment interesting. Unfortunately, I can't say the same for yours.

I don't even like contracts, but disliking contracts is not actually a core part of my identity.

[u/kammce → u/_a4z]

What does it mean for the contracts paper to be considered a paper tiger when its a usable feature? See Jason Turner's video on how to use: https://youtu.be/_H-RfRipIY0?is=dJqrZI5lfneelp95

It would be paper if it was all for shoe and unimplementable, but we have an implementation.

[u/_a4z → u/kammce]

Sure, but I guess there is a difference between a 5 to 10-minute compiler explorer exercise and a real-world project. The real-world project might end up with well-documented reasons why 26 contracts are unusable.

[u/_space_ghost_]

I think this talk will answer some of the questions found in the original OP link:
https://cppcon2026.sched.com/event/2RT6a/c++-core-guidelines-enforcement-in-practice
(edit, rephrasing)

[u/VinnieFalco]

I'm looking forward to this. I will be at CppCon if anyone wants to meet up and talk shop! if you are attending, check out the C++ Alliance pavilion where we will be revealing the Boost Collectable Card Game! Visit https://ccg.boost.org/

[u/rayaxiom → u/VinnieFalco]

There's an official card game from boost?! Wow. I see I can play against the compiler, is online pvp available? Make it available on steam!

[u/enceladus71 → u/rayaxiom]

Or in conan/vcpkg!

[u/PossibilityUsual6262]

Honestly, i don't have anything from Bjarne in recent memory which wasn't delusional marketing nonsense of no value, lets see if this is not like others.

[u/Orlha → u/PossibilityUsual6262]

observer_ptr counter-paper was alright

[u/donaljones → u/Orlha]

A bit off-topic, but what might it be useful for?

[u/AnyPhotograph7804 → u/donaljones]

It was intended to replace T*. Because if you see a naked pointer, you cannot see, whether it owns a ressource or not by looking at the type itself. You have to read the sourcecode to understand what is going on. By looking at experimantal::observer_ptr you would see, that this pointer is a non-owning pointer.

[u/scrumplesplunge → u/AnyPhotograph7804]

I feel like it's easy enough in modern C++ to ensure that raw pointers aren't ever owning pointers (edit: outside the limited scope of the implementations of small raii wrappers) and then just read T* as an observer without adding a more verbose spelling for it. Even when interfacing with third party libraries, I'd read the documentation once and then wrap owning things in smart pointers if necessary (e.g. using window_ptr = unique_ptr<GLFWwindow, delete_with<glfwDestroyWindow>>).

[u/AnyPhotograph7804 → u/scrumplesplunge]

Yes. But this applies to your code. In a company with old code bases, you will face code, which was written by a person, who is retired 15 years ago. And then, if you see a char* then have fun to figure out what it really is and who is responsible for its cleanup. And this was the purpose of experimantal::observer_ptr to add more context.

[u/ts826848 → u/Orlha]

P1408 "Abandon observer_ptr" or a different one?

[u/Orlha → u/ts826848]

This is it, yes

[u/ABlockInTheChain → u/ts826848]

Using both an owner and a non-owner (possibly called observer) alias could facilitate a transition as mentioned in "benefits."

T&: non-owning, not null, not rebindable

T*: unknown ownership, may be null, rebindable

std::span<T, 1>: non-owning, not null, rebindable

I can't recall ever seeing a use of std::span<T, 1> but it seems like it has a beneficial use case.

[u/Syracuss → u/ABlockInTheChain]

I can't recall ever seeing a use of std::span<T, 1> but it seems like it has a beneficial use case.

std::span<T, 1> exists for the same reason std::array<T, 1> exists, for generic programming. Having to write checks and alternative implementations to deal with just a 1 sized span would be annoying.

I wouldn't use it to replace non owning and rebindable when T* serves that function already in all modern codebases I've worked in. It would be massively confusing to see a span used for that as well. You're better off with a using statement if you really want to give it an obvious name in the code.

If it could be null outside of a span, it could still be null inside. That's really up to your coding practices to guard against.

[u/ABlockInTheChain → u/Syracuss]

If it could be null outside of a span, it could still be null inside. That's really up to your coding practices to guard against.

A function which accepts std::span<T, 1> as an argument type will not check that argument for null because it's not possible to perform the check. The type itself conveys the invariants and the only way the invariants could have been broken was to deliberately invoke undefined behavior.

T* has no invariant so local coding practices are the only way to know how to interpret it.

T& is still a better argument type for observing, but in any case where you have some compelling reason to take a non-owning T* instead of T& then std::span<T, 1> would be better.

[u/Syracuss → u/ABlockInTheChain]

I see how you're intending to use it now. It's bordering on "too clever". I'd flag it in a code review as it's a non-obvious usage of std::span and will definitely trip people up, but if you're going to use it like that why not just use std::ref/std::reference_wrapper? At least with that one the expected usage is easily visible in a code review.

edit: Your usage of span also makes it unnecessarily verbose to construct these spans. You can add some deduction guides or helpers, but still think std::reference_wrapper is a better fit as it does support the proper operations out of the box.

[u/ABlockInTheChain → u/Syracuss]

You can add some deduction guides or helpers

I have functions that take std::span<T, std::dynamic_extent> arguments, and a helper template function which will construct a std::span<T, 1> from a T& so that a single function overload can handle any number of input objects.

No functions which take std::span<T, 1> though.

[u/Syracuss → u/ABlockInTheChain]

If you're using dynamic_extent, then I don't see how your use case is related to observer_ptr. I'm so confused why you brought up std::span<T, 1> in this thread's context. But fair enough, if you need a variable sized span, then you should use span.

[u/ABlockInTheChain → u/Syracuss]

This thread made me realize that the std::span<T, 1> which I am incidentally creating for other purposes contains semantic information that makes relevant to the use case of observer_ptr.

[u/germandiago → u/Syracuss]

Related but not same: generic programming and void specializations...

I usually use std::monostate and get away with unnecessary, improductive duplications.

[u/selvakumarjawahar → u/PossibilityUsual6262]

This one: https://arxiv.org/abs/2510.08969. This paper, along with his presentation on this topic last year, motivated me to learn concepts more deeply and apply them in my code. So definitely not nonsense or of no value.

[u/pjmlp]

I will believe in profiles when VC++ analysis tooling, starting with Core Guidelines lifetime analysis without SAL annotations.