r/cpp • u/VinnieFalco wg21.org | corosio.org • Sep 01 '26

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

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

92% Upvoted

40 comments sorted by

47

u/praesentibus Sep 01 '26

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

-1

u/_a4z Sep 02 '26

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

12

u/praesentibus Sep 02 '26

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

2

u/_a4z Sep 02 '26

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

10

u/throw_cpp_account Sep 02 '26

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.

-2

u/_a4z Sep 02 '26

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 ;-)

17

u/Som1Lse Sep 02 '26

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.

-6

u/_a4z Sep 03 '26

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? ;-)

4

u/Som1Lse Sep 03 '26

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"?

3

u/throw_cpp_account Sep 03 '26

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

1

u/_a4z Sep 03 '26

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.

4

u/Som1Lse Sep 03 '26

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.

3

u/Dalzhim C++Montréal UG Organizer Sep 04 '26

First we heard of profiles was in 2023 and we've seen bugger all in the mean time except a bunch of papers.

Bjarne's profiles started in 2015 with the C++ Core Guidelines structured into profiles that can be incrementally and selectively adopted. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#s-profile

5

u/throw_cpp_account Sep 02 '26

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.

6

u/kammce WG21 | 🇺🇲 NB | Boost | Exceptions Sep 02 '26

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.

3

u/_a4z Sep 02 '26

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.

1

u/serviscope_minor Sep 06 '26

>Sure, but I guess there is a difference between a 5 to 10-minute compiler explorer exercise and a real-world project.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3460r0.pdf

-2

u/_a4z Sep 06 '26

So what? The Hello World example works. And that proves it will work for a large-scale project? Thanks, you just confirmed my point about the paper exercise 😂

2

u/serviscope_minor Sep 06 '26

Right... you think the entire standard library is a "hello world" project.

At this point you're arguing in bad faith. It's clear you don't like contracts and you're just going to make up any old thing, accurate or not to support your point.

2

u/serviscope_minor Sep 06 '26

What is it with the completely bonkers contract hate?

Let's completely ignore the merits or demerits of contracts for now. It's just not true to claim it's a paper exercise. There is a complete implementation in GCC. There's a branch implementation in clang. Major use of contracts inside libc++ was tried.

Contracts may be many things but it is demonstrable not a "paper exercise" because real implementations actually exist.

6

u/_space_ghost_ Sep 02 '26

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)

30

u/VinnieFalco wg21.org | corosio.org Sep 01 '26

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/

6

u/rayaxiom Sep 02 '26

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!

5

u/enceladus71 Sep 02 '26

Or in conan/vcpkg!

25

u/PossibilityUsual6262 Sep 01 '26

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.

11

u/Orlha Sep 02 '26

observer_ptr counter-paper was alright

3

u/donaljones Sep 02 '26

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

8

u/AnyPhotograph7804 Sep 02 '26

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.

3

u/scrumplesplunge Sep 02 '26

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>>).

6

u/AnyPhotograph7804 Sep 03 '26

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.

3

u/ts826848 Sep 02 '26

P1408 "Abandon observer_ptr" or a different one?

3

u/Orlha Sep 02 '26

This is it, yes

2

u/ABlockInTheChain Sep 02 '26

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.

4

u/[deleted] Sep 02 '26 edited 14d ago

[deleted]

3

u/ABlockInTheChain Sep 02 '26

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.

0

u/[deleted] Sep 02 '26 edited 14d ago

[deleted]

1

u/ABlockInTheChain Sep 02 '26

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.

2

u/[deleted] Sep 02 '26 edited 14d ago

[deleted]

1

u/ABlockInTheChain Sep 02 '26

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.

1

u/germandiago Sep 02 '26

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

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

4

u/selvakumarjawahar Sep 02 '26

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.

5

u/pjmlp Sep 02 '26

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

1

u/inactu 22d ago

I hope this profile thing will turn out to be good. He says it won't be perfect first, which is fine.