C++ has a proposal process for changes to the language and standard library (see also the ISO C++ wiki's page on "How To Submit a Proposal", the Std Proposals mailing list, the list of Standards Committee papers, and the papers repo on the cplusplus GitHub organization).

Programming-language design doesn't happen in a vacuum. For many language-building projects, there's a team of people working together- such as a committee (as is the case with C++).

For those who want to learn from a well-established language with a design committee- particularly from "mistakes" it may have made in terms of its culture surrounding design proposals, and how it is (potentially) learning from those mistakes,

What kinds of problems (and associated solutions / goals to strive for) have C++ committee members historically identified with their proposal culture?

Please either quote or paraphrase, but in either case, link also to the source.

  • 1
    $\begingroup$ I'm not sure this is on-topic ─ it is more about project management, teamworking culture and community-building. $\endgroup$
    – kaya3
    Commented May 20, 2023 at 4:12
  • $\begingroup$ @kaya3 I was hesitant too (to post this). But I think this question addresses a practical problem in the space of PL design. I defer to what I've already written in the question post. $\endgroup$
    – starball
    Commented May 20, 2023 at 4:15
  • $\begingroup$ There's a related meta question here, but I'm not sure how well it covers this kind of question. I mean "not sure" in a literal sense, rather than British understatement (-: It seems like something for the community to work out while we're in the beta phase. $\endgroup$
    – kaya3
    Commented May 20, 2023 at 4:29
  • 1
    $\begingroup$ @kaya3 I'm mulling a bit more over it. I think it has to do with how far away you go from the act of performing language design. This question is about PL design proposals and how people (collaboratively) do PL design proposals. I see this as one step away from the direct activity of doing the design itself. A question about community building is a step (or multiple) further from this I think. I might start another Q&A on meta about this. $\endgroup$
    – starball
    Commented May 20, 2023 at 5:19
  • $\begingroup$ related meta discussion: languagedesign.meta.stackexchange.com/q/235/251 $\endgroup$
    – starball
    Commented May 22, 2023 at 8:49

1 Answer 1


Here's what Bjarne Stroustrup said on this topic during the 2017 CppCon "Grill the Committee" panel (at t=14:23).

TL;DR: Bjarne observes that there's a lack of collaboration, a not very useful expectation for proposals to be made with details fully fleshed out, over-focus on technical details, and lack of focus on the problem and use-cases. He'd like to see a change towards the opposite: Starting with a clear problem and important use-cases (without expecting whoever raises the proposal to have a "perfect solution" ready), and then having the committee work collaboratively on designing solutions.

Jon (the host of the panel) asked the panel members:

You guys particularly are all associated with something you were pushing for, but in the committee, you could almost think of it as you wear two hats. You wear a hat where you're trying to push a particular proposal, and you wear a hat where you're trying to push back on proposals. 'Cause that's the game, right? So, I want to ask you to think about a situation and you don't all have to come up with this, but if we had some interesting stories that's what we'd want tonight, where you got pushed back, where you first thought it was kind of ridiculous, "okay I'll think about how to deal with that", and then realized, "oh wow, this proposal has really benefited because of something I hadn't thought through well" and at first, it wasn't an "oh wow, brilliant!" At first, it was like an (growls). But then you said, "no no, now I realize what's going on". Anyone want to fess up to that?


From my perspective, I think it's the wrong question. Because my ideal way of having proposal develop, is that you articulate a problem, and then you articulate sort of a first idea of how to solve that problem. And then, you discuss- in committee and outside- ways of approaching this and discuss how you'd like use cases to be worked out and what would look like good code once you have it. And once that discussion is going on, [a] proposal firms up with more precise syntax, more work on edge cases, and refinement. And I find that one of the problems with the current Committee is that people want finished proposals prepared, put forward with exact semantics, except syntax, and endless precise wording. And we end up talking about technical details rather than what I consider fundamental language design problems, which is basically "what's the problem and what's the fundamental way of dealing with it?" And we spent endless time discussing technical details before we've agreed if and what the problem is.


So do you believe, in general, the proposals that are coming to the Committee are trying to hard to have a full solution and [there] might be better proposals if they worked more on just defining use cases, defining edge cases, and giving much less thought to what the wording should be, and that kind of thing?


I... think so, yes. I think that the Committee should be more collaborative in developing solutions. I think that people come in with a proposal, and they defend it, as opposed to bring a proposal and see how it works out and then jointly work towards a solution. I think there are too much defensiveness, too many demands of perfection before the time.

  • 1
    $\begingroup$ The whole aspect of design by committee and the c++ in general is much maligned by those in other language communities but typically they have only one implementation to worry about, a relatively small body of legacy code to stay compatible with and they are subject to less scrutiny. There is a Q&A pair there which doesn't quite fit with this question. $\endgroup$ Commented May 26, 2023 at 8:22
  • $\begingroup$ That said, here is a counterpoint for #embed - thephd.dev/finally-embed-in-c23 - there is a lot to learn there $\endgroup$ Commented Jun 2, 2023 at 0:15
  • $\begingroup$ Bit more on that here - thephd.dev/c23-is-coming-here-is-what-is-on-the-menu $\endgroup$ Commented Jun 2, 2023 at 0:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .