Learning about C++ Direction Setting

Another blog post written wearing only my hat, rather than any Mozilla or TC39 Delegate related hats

Last year while considering some JavaScript standards evolution, I wanted to look into how C++ handles some of the challenges. I dug through some documents, and wanted to share some of my findings here as a pointer for future discussion.

Design Aims

One of the fascinating artifacts is a set of C++ design aims, located in “Notes on Operating Principles for Evolving C++” , Appendix A¹.

I love the opinionated nature of this list, some pieces of which you could lift-wholesale into JS:

  • C++’s evolution must be driven by real problems.
  • It is more important to allow a useful feature than to prevent every misuse.
    • Enable good programming rather than to eliminate bad programming
  • If in doubt, pick the variant of a feature that is easiest to teach.

I personally really resonated with:

Prefer generality over specificity: prefer standardizing general building blocks on top of which domain-specific semantics can be layered, as opposed to domain-specific facilities on top of which other domain-specific semantics can't be layered

Which would support my insane quest for user defined primitives.

One recurring theme in the documents I read was the idea that C++ would require teaching and learning support, and that teaching and learning is a key principle when doing design for the language. This is something I’ve not heard made explicit very frequently in JS discussions.

The Direction Group

A fascinating aspect of the C++ committee is the existence of the Direction Group:

The direction group is a small by-invitation group of experienced participants who are asked to recommend priorities for WG21. Currently, that group consists of: Howard Hinnant, Roger Orr, Bjarne Stroustrup, Daveed Vandevoorde, and Michael Wong. Their charter includes setting forth a group opinion on:

  • Evolution direction (language and library): This includes both language and library topics, and includes both proposals in hand and proposals we do not have but should solicit. The direction group maintains a list of the proposals it considers the most important for the next version of C++ or to otherwise make progress such as in a TS, and the design group chairs use that list to prioritize work at meetings. Typically, work on other topics will occur after there’s nothing further left to do at this meeting to advance the listed items.
  • Providing an opinion on any specific proposal: This includes whether the proposal should be pursued or not, and if pursued any changes that should be considered. Design group participants are strongly encouraged to give weight to an opinion that the direction group feels strongly enough about to suggest.

They have produced a document, “Directions for ISO C++” which functions as both a highlighter of many of the legitimate challenges of C++ design-by-committee, as well as a finger-on-the-scale to attempt to drive priorities.

They explicitly call out some time scales when discussing their priorities:

  • Long Term (Decades)
  • Medium Term (3-10 Years)
  • Short term (The next few releases)

I find this notion fascinating, and perhaps something that is worth trying to work into T39.

I really appreciate the pragmatic discussions in this document as well, much of which writes down things we see in JS, but perhaps don’t document nearly as explicitly. Apologies for the length of the quote, but I think it’s good:

All proposals consume the (limited) committee time, and WG21 members should consider the best overall outcome for the future of the language. Hence, while small proposals to clean up non-trivial defects are welcome, discussion about these may have lower priority. If such a small proposal proves to be controversial, it is probably better to withdraw or defer it to avoid preventing progress on more substantive items.

We are a set of interrelated committees currently with about 200 members present at a meeting and more active via the Web. Thus some “design by committee,” or rather “design by committees,” is unavoidable. We need to consciously and systematically try to minimize those effects by building a shared sense of direction.

  • We have no shared aims, no shared taste.
    • This is a major problem, possibly the most dangerous problem we face as a committee. For C++ to succeed, we must overcome that. For starters, we – as individuals, as SGs, as WGs, and as the committee as a whole – must devote more time to develop and articulate a common understanding. In particular, for every proposal being considered, we should do more to emphasize the motivation and explain how it fits in the language, standard library, and common uses that we anticipate.
  • The alternative is a dysfunctional committee producing an incoherent language
    • We need to be more explicit about:
      • What general problems we are trying to address
      • How a particular proposal serves those articulated aims

I don’t know how the chairs manage these sorts of issues at TC39, but I really appreciate the candour here – similarly with their frank discussion of process issues:

We are “a bunch of volunteers.”

  • Most are enthusiasts for some aspect of the language or other.
  • Few have a global view (geographically, C++ community, C++ usage, C++ Language and standard library).
  • Most have a strong interest in only some subset of use, language, or library.
  • Most are deeply engaged with a specific form of C++ as part of their daily work.
  • Our levels and kinds of relevant computer-science, design, and programming-language education vary dramatically.
  • Many are clever people attracted to clever solutions.
  • Some are devoted to ideas of perfection.
  • Many are tool builders.
  • Some have full control over their source code whereas others critically rely on code outside their direct control (open-source and/or commercial).
  • Some operate in an environment with strong management control, others in environments without a formal management structure (and everything in-between).

This implies that we can’t rely on a common vocabulary, a core set of shared values, a common set of basic ideals, or a common understanding of what’s a problem. Consequently, we must spend more effort on:

  • Articulating rationales for proposals.
  • Facilities for the “average programmer,” who is seriously under-represented on the committee.
  • Facilities aimed more at application builders than at builders of foundational libraries.

Please pay special attention to that last point. We feel that C++’s utility and reputation suffer badly from the committee lacking attention to improvements for relative novices and developers with relatively mundane requirements. Remember:

  • Most C++ programmers are not like the members of the committee.

    We, as a committee, have no mechanism of reward (except accepting someone’s proposal) or punishment (except delaying or rejecting someone’s proposal). To get something accepted, we need consensus (defined as large majority, but not necessarily unanimity). This has implications on what we can do and how we do it.

  • Nothing gets done unless someone cares enough to do it.

  • A small vocal minority can stop any proposal at any stage of the process.

The majority of which will feel familiar to those working with TC39 in my opinion.

The authors of the Directions paper also explicitly highlight the importance of trust in the process, and the failures that have caused loss of trust. These will sound familiar to TC39 participants – the broader committee (plenary) stomping all over a working groups (champions group’s) careful design work, late breaking feedback and failure of consensus based on “lack of comfort”.

I do feel the pain behind this sentence, “People who were not sufficiently motivated to take part in the discussion should feel obliged to at least stay neutral“, though I think with the breadth of C++ it understates the amount of effort required to stay on top of everything.

Some of the guidance from the direction group… I wish we had anything equivalent in TC39:

When triaging features for consideration, we propose that the WG chairs put a higher priority on features that conform to these goals, but also keep a watch against features that:

  • Turn C++ into a radically different language
  • Turn parts of C++ into a significantly different language by providing a segregated sub-language
  • Have C++ compete with every other language by adding as many as possible of their features
  • Incrementally modify C++ to support a whole new “paradigm” without articulating the end goal
  • Hamper C++'s use for the most demanding systems programming tasks
  • Increase the complexity of C++ use for the 99% for the benefit of the 1% (us and our best friends)

The misfires of TC39, in my opinion, are often covered by exactly these sorts of comments.

The C++ Programmer’s ‘Bill Of Rights’

This is a peculiar section, but I think interesting as a thought experiment: What would a JS programmer’s ‘bill of rights’ look like; we know there are some aspects to this:

  • Don’t break the web.
  • ???

But what does the rest of this look like?

Acknowledgements:

Thanks to Botond Ballo for an email conversation which guided me to many of these sources. Much appreciated.

¹: The C++ Committee’s love of PDFs is truly baffling and an absolute pain in the butt. Most of these quotes were massaged back into semi-coherent formatting by copying garbage out of a PDF and then having ChatGPT recreate some semblance of the original. As a result, take these quotes as having statistical similarity to the original document, but not 100% coherence. However, I link to the source in case there’s wording concerns.