On Sat, Jun 27, 2020 at 9:22 PM Edward Diener via Boost < boost@lists.boost.org> wrote:
On 6/27/2020 1:55 PM, Ville Voutilainen via Boost wrote:
On Sat, 27 Jun 2020 at 18:48, Edward Diener via Boost
wrote: You have raised a bunch of hackles here. The LEWG, along with all other C++ standard committees, seems to me so much less open to debate than Boost is that it is hard to know what to say about your assertion that "This list is not very welcoming". Nor can anything ever be found out from the C++ standards committee why such and such was accepted or rejected, or what the arguments were about after the fact.
Have you tried asking a committee member, or just asking on std-discussion? It also seems to me that there tends to be a multitude of meeting trip reports that cover why such and such was accepted or rejected.
I do not find that the reasons why a proposal is accepted or rejected, as well as the differing opinions of those reviewing the proposal, are available for C++ Standard committees. Yet anyone can search Boost
archives for discussions regarding a library submitted to Boost, since
they are all part of the Boost developer mailing list. Therefore while I respect the expertise of those on the various C++ standard committees, and while I understand that those who are on the various C++ standard committees change over time, the lack of historical information
I guess I don't see this as generally the case wrt specific proposals. Most papers, tend to maintain a running history of relevant decisions and that's usually the best source of what transpired. Look at one of mine -- on page 2 there there's a summary related to LEWGI and SG10 feedback. Section 6 goes into more detail on a number of these. Authors do this to help remind themselves and help committee members (meaning cut down rediscussion of already hashed thru points) that aren't able to be in every single discussion of the paper. To me this is actually better than trying to search the mailing list. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1750r1.pdf
regarding proposals is a huge negative IMO. I am not against experts making decisions in any field, but I am always against those decisions not being open so that other people can see the reasons, even after the fact, for decisions being made. This is especially true in our age, where digital records can provide information much more easily than libraries of printed information could in the past. I believe everyone has a right to protect personal information, but at the same time I believe public information should be open to anyone.
98% of it is. Of course it just won't have the fidelity of have 'been in the room'...
poobahs of the C++ standard committee I have often found to be largely unfriendly and closed in their determination that only they really know what is good or not for C++.
Sure; some of them need a fairly strong rationale to be convinced
otherwise. :)
I think it is more like some of them are too egotistical to even listen to others who do not have their own reputation.
If these people exist, I haven't met them yet. And I've spent an unhealthy amount of time participating....
But that is true in any field and while I have encountered some who were like that I have also dealt with some others who were pretty open to technical arguments. Nonetheless I find that even if the debates in Boost get fairly contentious sometimes, it is always better to have the debate rather than avoid argumentation out of some preconceived notion of "niceness".
'Contentious debate' over things that should be non-issues is a feature of our current broader context. To give a Boost example, though, I find all review comments of the form "this doesn't solve my use case so I won't use the library - I vote to reject" hostile and not helpful. The fact that a library doesn't solve your use case is one 'data point' -- good, supply that as a fact. The question at hand in a review is if the library solves a need for many users. If you would vote against something that others might find useful that lessons the value of your opinion in my book. Jeff