<p>C++ has a proposal process for changes to the language and standard library (see also <a href="https://isocpp.org/std/submit-a-proposal" rel="noreferrer">the ISO C++ wiki's page on &quot;How To Submit a Proposal&quot;</a>, <a href="https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals" rel="noreferrer">the Std Proposals mailing list</a>, <a href="https://www.open-std.org/jtc1/sc22/wg21/docs/papers/" rel="noreferrer">the list of Standards Committee papers</a>, and <a href="https://github.com/cplusplus/papers/issues" rel="noreferrer">the papers repo on the cplusplus GitHub organization</a>).</p>
<p>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++).</p>
<p>For those who want to learn from a well-established language with a design committee- particularly from &quot;mistakes&quot; it may have made in terms of its culture surrounding design proposals, and how it is (potentially) learning from those mistakes,</p>
<p>What kinds of problems (and associated solutions / goals to strive for) have C++ committee members historically identified with their proposal culture?</p>
<p>Please either quote or paraphrase, but in either case, link also to the source.</p>

<language-design><c++>
What can be learned from problems (and associated solutions / goals to strive for) C++ committee members have identified with their proposal culture?
CC BY-SA 4.0
2023-05-20T04:12:28.387Z
I'm not sure this is on-topic ─ it is more about project management, teamworking culture and community-building.
kaya3
CC BY-SA 4.0
2023-05-20T04:15:55.760Z
@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.
starball
CC BY-SA 4.0
2023-05-20T04:29:09.480Z
There's a related meta question [here](https://languagedesign.meta.stackexchange.com/q/94/89), 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.
kaya3
CC BY-SA 4.0
2023-05-20T05:19:10.847Z
@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.
starball
CC BY-SA 4.0
2023-05-22T08:49:19.323Z
related meta discussion: https://languagedesign.meta.stackexchange.com/q/235/251
starball
CC BY-SA 4.0
2023-05-26T08:27:49.543Z
Do you mean this question to be C++ specific? I feel there are at least two other questions itching to come out here like:
1) What are a good and bad ways to evolve a language and why are they good or bad.
2) What has been good about the process for evolving C++ (this Q seems to emphasize the bad).
I've put a micro answer to that as a comment to @starball 's answer.
Bruce Adams
CC BY-SA 4.0
2023-05-26T08:55:38.817Z
@BruceAdams yep. purposely C++ specific, and purposely about problems. you can post those other questions that you want to see ::)
starball
CC BY-SA 4.0
2023-05-26T08:58:50.153Z
I think  1) What are a good and bad ways to evolve a language and why are they good or bad. - would require a sandbox and/or lots of community input to phrase well.
Bruce Adams
<p>Here's what Bjarne Stroustrup said on this topic during <a href="https://youtu.be/JYG5LFHkUuE?t=868" rel="noreferrer">the 2017 CppCon &quot;Grill the Committee&quot; panel (at t=14:23)</a>.</p>
<p>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 &quot;perfect solution&quot; ready), and then having the committee work collaboratively on designing solutions.</p>
<p>Jon (the host of the panel) asked the panel members:</p>
<blockquote>
<p>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, &quot;okay I'll think about how to deal with that&quot;, and then realized, &quot;oh wow, this proposal has really benefited because of something I hadn't thought through well&quot; and at first, it wasn't an &quot;oh wow, brilliant!&quot; At first, it was like an (growls). But then you said, &quot;no no, now I realize what's going on&quot;. Anyone want to fess up to that?</p>
</blockquote>
<p>Bjarne:</p>
<blockquote>
<p>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 &quot;what's the problem and what's the fundamental way of dealing with it?&quot; And we spent endless time discussing technical details before we've agreed if and what the problem is.</p>
</blockquote>
<p>Jon:</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>Bjarne:</p>
<blockquote>
<p>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.</p>
</blockquote>

CC BY-SA 4.0
2023-05-20T00:01:47.293Z
2023-05-20T00:01:47.293Z
starball
CC BY-SA 4.0
2023-05-26T08:22:46.187Z
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.
Bruce Adams
CC BY-SA 4.0
2023-06-02T00:15:48.413Z
That said, here is a counterpoint for #embed - https://thephd.dev/finally-embed-in-c23 - there is a lot to learn there
Bruce Adams
CC BY-SA 4.0
2023-06-02T00:23:51.917Z
Bit more on that here - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu
Bruce Adams
# What can be learned from problems (and associated solutions / goals to strive for) C++ committee members have identified with their proposal culture?
Posted by: username_0 on 2023-05-20
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"](https://isocpp.org/std/submit-a-proposal), [the Std Proposals mailing list](https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals), [the list of Standards Committee papers](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/), and [the papers repo on the cplusplus GitHub organization](https://github.com/cplusplus/papers/issues)).

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.
**Tags:** language-design c++
> **Comments:**
> **username_1**: I'm not sure this is on-topic ─ it is more about project management, teamworking culture and community-building.  
> **username_0**: @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.  
> **username_1**: There's a related meta question [here](https://languagedesign.meta.stackexchange.com/q/94/89), 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.  
> **username_0**: @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.  
> **username_0**: related meta discussion: https://languagedesign.meta.stackexchange.com/q/235/251  
> **username_2**: Do you mean this question to be C++ specific? I feel there are at least two other questions itching to come out here like:
1) What are a good and bad ways to evolve a language and why are they good or bad.
2) What has been good about the process for evolving C++ (this Q seems to emphasize the bad).
I've put a micro answer to that as a comment to @starball 's answer.  
> **username_0**: @BruceAdams yep. purposely C++ specific, and purposely about problems. you can post those other questions that you want to see ::)  
> **username_2**: I think  1) What are a good and bad ways to evolve a language and why are they good or bad. - would require a sandbox and/or lots of community input to phrase well.  
---
## 1 answers
### Answer by username_0 on 2023-05-20. Score: 6
Here's what Bjarne Stroustrup said on this topic during [the 2017 CppCon "Grill the Committee" panel (at t=14:23)](https://youtu.be/JYG5LFHkUuE?t=868).

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?

Bjarne:

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

Jon:

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

Bjarne:

> 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.
> **Comments:**
> **username_2** (2023-05-26): 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.  
> **username_2** (2023-06-02): That said, here is a counterpoint for #embed - https://thephd.dev/finally-embed-in-c23 - there is a lot to learn there  
> **username_2** (2023-06-02): Bit more on that here - https://thephd.dev/c23-is-coming-here-is-what-is-on-the-menu  
---
