On September 15, 2026, CppCon 2026 is scheduled to host a Language Designers Panel with Bjarne Stroustrup, Guido van Rossum, and Mads Torgersen. Emma Tracey will moderate a conversation that puts C++, Python, and C#—three languages with very different design traditions—at the same table.

The interesting part is not merely the possibility of hearing about future features. When a language has decades of users and code behind it, what must its designers preserve, where can they compromise, and when should an idea be exposed to real users?

There is an important boundary, though: a statement made on a panel is not automatically a language decision. To make the session practically useful, let us first locate each language in its current cycle, then look at where its decisions are actually made.

C++26, Python 3.15, and C# 15 are at different stages of maturity

The session is scheduled for 10:30 a.m. to noon MDT on September 15, 2026, which is 1:30 to 3:00 a.m. JST on September 16. The official CppCon announcement says that 2026 conference sessions are onsite-only and are expected to be recorded and posted to YouTube afterward.

All three languages are moving toward another release or standard, but “in development” does not mean the same thing for each one.

Language	Position as of August 31, 2026	What to separate while listening
C++	C++23 is published and C++26 work is underway	Work-in-progress proposals from the eventual standard
Python	3.15.0rc1 shipped on August 4, with the final release scheduled for October 1	Release-candidate behavior from ideas for later versions
C#	C# 15 is the latest preview available with .NET 11 previews	Public previews and incomplete features from shipped language behavior

A panelist may therefore be talking about a concept, a proposal, a preview implementation, or a nearly final release. The useful follow-up to “that sounds promising” is “where exactly is it in that progression?”

C++, Python, and C# make language decisions in different places

The three panelists have substantial influence over their languages. Modern language specifications are nevertheless not created by one person speaking from a stage. Understanding the formal paths turns the panel from a source of predictions into a discussion of design judgment.

For C++, an idea is developed into a document that explains the problem, alternatives, and design; it is revised through feedback and can become a numbered paper for the relevant committee group. Standard C++ documents this path from initial idea through drafts and committee consideration in How To Submit a Proposal.

Python describes language features and implementations through Standards Track PEPs, supported by public discussion and a reference implementation. PEP 1 assigns final authority to the Steering Council or an appointed PEP-Delegate and requires proposals with backward incompatibilities to explain their impact and treatment. PEP 13 also records the governance transition after Guido van Rossum stepped down as BDFL in July 2018; Python is now governed around an elected Steering Council.

For C#, the Language Design Team works with the Roslyn team through discussions, proposals, Language Design Meetings, and, when needed, prototypes. The official csharplang repository explicitly warns that an active proposal is not guaranteed to enter any future version and may be postponed or rejected after design, implementation, compatibility, or testing feedback.

The differences are not just about who has the final say. The languages differ in where rationale is recorded, how implementation experience feeds back into design, and which artifact represents a decision. Those decision criteria are often more useful than a single yes-or-no answer about a feature.

Break “evolving without breaking users” into three kinds of cost

The panel description asks how designers steer languages with millions of users and decades of code without breaking the people who depend on them. This is not a binary choice between compatibility and progress. It is a question of who absorbs each cost.

A useful way to listen is to separate three kinds of burden:

• Existing-code cost: recompilation, rewrites, warnings, or behavior changes
• Ecosystem cost: whether compilers, IDEs, libraries, and packages can keep up
• Learning cost: whether old and new styles can coexist without making guidance incoherent

A shorter syntax may look attractive while increasing parser, tooling, or teaching complexity. A safer default may help new code yet still need a migration path if it changes the meaning or build result of existing code.

For each proposal or preference mentioned, ask three questions: What concrete problem does it solve? Who pays the migration cost? What evidence is needed before it moves from experiment or preview to a stable decision? These questions make the tradeoffs comparable even when the languages are not.

Mixed C++–Python and C++–C# systems expose design choices at their boundaries

CppCon did not frame this as a purely cross-community curiosity. Its announcement points to the annual C++ developer survey, where Python use among C++ respondents has remained around 70%, and to the frequent pairing of native C++ and managed C# in Windows software.

When a C++ library is exposed to Python, API quality depends on how ownership, errors, and data conversion cross the boundary. When a C# application calls native C++ components, lifetime, exceptions, and deployment boundaries also become part of the design.

That makes one question especially practical: what does each language ask programmers to state explicitly, and what does it delegate to the implementation or runtime? The answer can sharpen decisions in library and service APIs, where convenience, predictability, and migration rarely peak at the same point.

Track panel remarks without turning them into specification claims

While watching, classify notable statements into four groups:

1. A problem the speaker believes should be solved
2. A design the individual speaker prefers
3. A proposal under a formal language process
4. A feature accepted into a specification or implementation

Afterward, return to WG21 papers and status pages for C++, the Status and Python-Version fields of relevant PEPs for Python, and csharplang proposals, meeting notes, and implementation status for C#. Save the date of the remark as well; language designs can change after a useful public discussion.

Readers outside the venue will need to wait for the planned recording. No publication date or video URL has been announced, so the CppCon site and official channel remain the places to watch for availability.

The practical takeaway is a decision framework, not a feature forecast

The panel's value is not in predicting the next C++, Python, or C# feature. It is the opportunity to compare how three languages with different histories and governance models prioritize compatibility, implementability, and teachability when facing similar design questions.

The durable takeaway is a way to ask: Which problem is being solved, whose cost does the solution create, and what validation turns it into a decision? With that framework, later proposals and release notes become more than lists of changes; they reveal the engineering argument behind the language's direction.

Source

• Title: CppCon 2026 Keynote: Language Designers Panel -- Tracey, Stroustrup, Van Rossum, and Torgersen
• URL: https://isocpp.org//blog/2026/08/cppcon-2026-keynote-language-designers-panel-tracey-stroustrup-van-rossum-a