What should the ISO C++ Standards Committee be doing?

Bjarne Stroustrup

There is a lot of talk within the committee and outside about how to chose what to work on, what processes will work best for handling proposals, and how to maintain a direction for the language.

In January, a group of heads of national delegations submitted a document entitled Operating principles for evolving C++ and the committee constituted a small group of experienced members to try to develop and maintain direction of the standards effort.

In June, Titus Winters and the members of the direction group submitted a follow-up document: C++ Stability, Velocity, and Deployment starting the process of making the principles real. This document was presented at the Toronto meeting to about 80 members in an evening session. It was very well received.

We are working to make the suggestions from those papers concrete to improve the standards process, and eventually help improve C++ and its ISO standard. Here, I would like to direct attention to one part of that document:

Proposal – “Our Promise To Users” a.k.a

“The C++ Programmers’ Bill of Rights.”

We, the ISO C++ Standards Committee, promise to the best of our ability to deliver the
following, assuming user code adheres to the current standard:

1. Compile-time stability: Every change in behavior in a new version of the standard is detectable by a compiler for the previous version.
2. Link-time stability: ABI breakage is avoided except in very rare cases, which will be welldocumented and supported by a written rationale.
3. Compiler performance stability: Changes will not imply significant added compile-time costs for existing code.
4. Run-time Performance stability: Changes will not imply added run-time costs to existing code.
5. Progress: Every revision of the standard will offer improved support for some significant programming activity or community.
6. Simplicity: Every revision of the standard will offer some simplification of some significant programming activity.
7. Timeliness: The next revision of the standard will be shipped on time according to a published schedule.

Note “to the best of our abilities”. These are guiding principles, rather than executable statements. For example, if I add a function to a header file, the compilation of code that includes that header will slow down imperceptibly. That’s understood and could be argued not to be “existing code” because of the change. Adding enormous amounts of code to a header so that compilation slowed down noticeably
would be another matter.

These are ideals. They are what we would like to see done. I we succeed, most users will be very happy. However, they are not a recipe we could blindly follow to deliver a new standard. As is typical for ideals, they can conflict: there are tensions among the desired goals. This is common: Ideally, we want quality, on-time delivery, and low cost of products, but we know from vast experience that it is very hard to get all three. We want freedom of speech and absence of verbal intimidation, but balancing those two can be very hard. It is the same for the ideals of the “The C++ Bill of Rights”; we want all, but the committee will have to make hard choices.

These are ideals. They are meant to be rather grand statements, rather than nit-picked long sentences with every statement watered down by adjectives and caveats. It will be up to the committee members to interpret the ideals for real design and scheduling problems.

There are just 7 ideals listed and they are quite general. We could add many more, but a laundry list of specifics, would dull the appeal and be impossible to remember in the heat of discussions about direction, what can be delivered when, and specific technical concerns.

So, what do you think? Should the committee formally commit to this? Can it be improved? How? Obviously, we need a discussion within the committee and in the community in general before deciding on anything.