Le lundi 15 mars 2021 à 19:50 +0200, Peter Dimov via Boost a écrit :

I'm looking into adding support for overloaded functions.

I also already made the following changes in response to review feedback:

* Removed BOOST_DESCRIBE_ENUM_CLASS;

I'd rather you did *not* make that specific change. I find it useful and convenient (i will end up copying it into an own header, and i expect a lot of users to do the same). There is maybe some room for an "extra" header, which would contain additional features that a lot of users will find useful, but which are not strictly speaking part of the core library. String to enum and enum to string conversion could also fit this (i failed to notice it during the review, but i later realized they can be provided in terms of c++17 to_chars / from_chars API – i wrote a working POC that i'll happily PR once polished a bit). Regards, Julien

Le lundi 15 mars 2021 à 20:11 +0200, Peter Dimov a écrit :

Julien Blanc wrote:

...

...

* Removed BOOST_DESCRIBE_ENUM_CLASS;

I'd rather you did *not* make that specific change. I find it useful and convenient (i will end up copying it into an own header, and i expect a lot of users to do the same).

Not sure if we understand one another here; the reason I removed BOOST_DESCRIBE_ENUM_CLASS was that, as pointed out by reviewers, the same macro can work for both scoped and unscoped enums. So I made BOOST_DESCRIBE_ENUM work for both, and removed the other one, which was now redundant.

BOOST_DEFINE_ENUM_CLASS is still there.

Yes, definitely misunderstood you. Sorry for the noise, thanks for the clarification. Regards, Julien

On Mon, 15 Mar 2021 at 19:54, Robert Ramey via Boost wrote:

On 3/15/21 9:48 AM, Richard Hodges via Boost wrote:

...

Boost Describe Review Summary

Exercise for the reader:Contrast the Boost procedures for achieving approval with that of the C++ committee. What does this teach us - if anything?

Thank you Robert. I have taken your clarification to heart. It will no doubt be useful in the upcoming review of Boost.MySQL, which is likely to be _a lot more controversial_. I do understand that not all votes have equal weight. I was careful to judge the reasoning behind the stated conditions, and took note of the back-and-forth on the list during the ten days. I fully agree with regard to the committee. It has been nothing but a cause of frustration and anger for the community of developers who actually use C++ to get work done. I have the strong impression that very few on the committee ever produce anything of strategic value for their employers.

Robert Ramey

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212

On 15/03/2021 19:01, Richard Hodges via Boost wrote:

I fully agree with regard to the committee. It has been nothing but a cause of frustration and anger for the community of developers who actually use C++ to get work done. I have the strong impression that very few on the committee ever produce anything of strategic value for their employers.

This is about as categorically untrue as any statement could be. As a general rule, those who regularly attend WG21 meetings are responsible for enterprise level software, having in large part contributed to the design, implementation, and maintenance of those mission critical systems. Think the libraries and services which underpin the whole functioning and being of Facebook, Google, Apple, Microsoft and so on, which hundreds of thousands of developers in those orgs use daily, and which generate billions of dollars annually in profits, either through cost reductions/efficiency savings, or by direct generation of value. There are large variations in opinion, yes, and reaching consensus always leaves everybody unsatisfied by definition. There is also often frustration that what is being standardised is very far from what everybody would prefer, but the committee standardises what is presented, not what it would have if there were infinite resources. Most of the perceived shortcomings with how the sausage is minced is mainly due to lack of funding of ecosystemic and public goods and services such as a package manager. That WG21 literally does not have the power to change, yet is typically blamed for, which is unfair. Niall

On 15.03.21 22:37, Emil Dotchevski via Boost wrote:

The committee seems to be concerned more with internal and external politics than with serving the community. If that wasn't true there would be ZERO library additions that haven't been battle hardened by being deployed and established themselves as the defacto standard already.

That's just bullshit. Right or wrong, good or bad, there are plenty of reasons for pushing for a library addition without waiting for a third-party library to establish itself as a de facto standard that have nothing to do with politics. For example: - There is a profusion of different libraries solving this problem, none of them individually popular enough individually to become a de facto standard. These libraries cannot talk to each other, splintering the community. - To proactively prevent the situation outlined above before it happens. - There is a clear need for a library, but the community has not yet produced such a library. - There is a clear need for a library, but the community /cannot/ produce such a library because it requires compiler support. Even if you think that all of these reasons are bad reasons, you should still acknowledge that they may have good intentions behind them and that they are not necessarily politically motivated.

The only thing they should be doing is rubber-stamping libraries that are already the standard for doing something. Instead, it's like a giant tube for force feeding us what we don't want (or else we would have adopted it already). For our own good of course.

If a library is already an established de facto standard, then there's little point in adding it to the C++ Standard, and a good reason for not doing so: it splinters the community, which is the opposite of what a standard should do. Example: I use Boost.Filesystem. I like Boost.Filesystem. Then std::filesystem shows up. Now I have to choose between Boost.Filesystem and std::filesystem. Boost.Filesystem is probably ahead in terms of features, but std::filesystem is the standard. Regardless of which one I pick, I may run into problems interfacing with third-party libraries that use the other one. -- Rainer Deyke (rainerd@eldwood.com)

On 16.03.21 23:42, Emil Dotchevski via Boost wrote:

"Splintering the community" simply means that there is not yet a standard way for doing something. Either all the available libraries have issues, or the problem being solved has multiple valid solutions. In the former case, develop a library that works better than the rest. In the latter case, the fact that no standard emerges is a good thing -- adding yet another way for doing something benefits nobody.

Or all of the libraries are functionally identical, and the main reason for choosing one over the other is compatibility with other third-party libraries.

I'm not interested in discussing the authors' motivation, that is irrelevant. When I mentioned politics, I meant that there are politics involved in the decision making process in the committee, not that the politics are motivating anyone.

The statement to which I was responding was this:

...

On 15.03.21 22:37, Emil Dotchevski via Boost wrote:

...

The committee seems to be concerned more with internal and external politics than with serving the community. If that wasn't true there would be ZERO library additions that haven't been battle hardened by being deployed and established themselves as the defacto standard already.

This is very much talking about the motivation (or "concern") of the committee. Criticize the processes, policies, priorities, and results of the committee all you want. But if you actually want to convince people on the committee of your point of view, you're going to have to present a stronger argument than "if you don't do it my way, you've been corrupted by politics." -- Rainer Deyke (rainerd@eldwood.com)

On 17/03/2021 18:02, Emil Dotchevski via Boost wrote:

If your goal is standardization, convincing the users is utterly irrelevant to success. Worse, it is a lose-lose proposition, you might get one and a half stars on GitHub which doesn't look too good. I remember Niall giving (good) advice that if the goal is standardization, it is best to not bother with a Boost review, either: it adds a lot more work that is irrelevant to achieving your goal, plus you risk rejection which doesn't look too good.

That's not _quite_ what I advised, though it is close. My advice was, and always has been, that the most valuable aspect of Boost _to the library_ and its author is the peer review. A high quality review is quite literally priceless - it cannot be bought for money. It's why I get so annoyed when some proposers only care about getting into Boost at all costs, that the review is only a hurdle which can be beaten down using groupies, which feels to me an enormous wasted opportunity to make the best C++ libraries possible. In this aspect, Boost has been very good for me. Both of the libraries I presented to Boost - AFIO and Outcome - both were completely reimplemented and completely redesigned from the feedback received here. I personally believe that the reason why WG21 has to date liked my libraries so much is precisely because of those Boost reviews. So thank you Boost! What you may be remembering me saying Emil is that once you get the review from Boost, the incentive to finish the library and get it into Boost is low if your goal is standardisation. You can skip rewriting all that documentation and tutorials and examples and having to deal with real end users for the next two decades if you go straight from Boost review to WG21 standards, skipping finishing your library sufficient for Boost. Given the plethora of C++ package managers today including github, Boost as a distribution vehicle is nothing like as important as it once was, so all in all, the value added from shipping in Boost is a fraction of what it was fifteen or twenty years ago. I skipped Boost and went straight to WG21 with LLFIO, and I feel very guilty about it. I did do the honourable thing for Outcome however. And I'll never, ever, get another library into Boost again unless someone is paying me to do it. Once is enough.

As for convincing the committee, I don't think that's possible from the outside, much less on this platform.

Most of the senior committee skim reads this mailing list. Most read the review manager summaries of new libraries in detail. Most of the big names are here, watching. Just because they never, or very rarely, post here doesn't mean they aren't reading. I can definitely assure you that what goes here changes opinions and persuades people on WG21. On many occasions I have discussed things happening here at WG21 meetings. You all here just never see it, that's all. Niall

On Thu, Mar 18, 2021 at 11:05 AM Edward Diener via Boost wrote:

Most good C++ programmers probably view getting a library into Boost as an indication of their ability and also a great experience in hearing what their peers think.

Outcome got into Boost. Thanks

On Thu, Mar 18, 2021 at 1:37 PM Edward Diener via Boost wrote:

...

Outcome got into Boost.

I did not say it had not

My response was not to you. Rather, it was the general observation that exceptions to rules exist. Thanks

On 15/03/2021 21:37, Emil Dotchevski wrote:

On Mon, Mar 15, 2021 at 1:21 PM Niall Douglas via Boost mailto:boost@lists.boost.org> wrote:

...

On 15/03/2021 19:01, Richard Hodges via Boost wrote:

...

I fully agree with regard to the committee. It has been nothing but a cause of frustration and anger for the community of developers who actually use C++ to get work done. I have the strong impression that very few on the committee ever produce anything of strategic value for their employers.

This is about as categorically untrue as any statement could be.

As a general rule, those who regularly attend WG21 meetings are responsible for enterprise level software, having in large part contributed to the design, implementation, and maintenance of those mission critical systems.

The committee seems to be concerned more with internal and external politics than with serving the community. If that wasn't true there would be ZERO library additions that haven't been battle hardened by being deployed and established themselves as the defacto standard already.

The only thing they should be doing is rubber-stamping libraries that are already the standard for doing something. Instead, it's like a giant tube for force feeding us what we don't want (or else we would have adopted it already). For our own good of course.

Most libraries presented for standardisation ARE battle hardened libraries. However they were typically written for preceding C++ standards, and in outdated idioms and design patterns, and require modernisation which can involve substantial refactoring. Something not appreciated outside the committee is that both the library proposer(s), and their experienced users, often also want substantial refactoring after their empirical experience. It makes sense to make use of that experience rather than ignoring it. I speak here of the typical case, which are all those libraries which get standardised with little fanfare nor notice, which is the vast majority. Only for a small, though highly visible, subset has there been substantial design by committee. A lot of that is due to my aforementioned explanations, which are not due to politics, but rather resourcing (or lack thereof). Niall

On 16/03/2021 12:52, Glen Fernandes wrote:

On Tue, Mar 16, 2021 at 6:17 AM Niall Douglas wrote:

...

Something not appreciated outside the committee is that both the library proposer(s), and their experienced users, often also want substantial refactoring after their empirical experience.

Note that Richard Hodges is inside the committee (just in case that wasn't clear to anyone else).

This is news to me. I don't recall reading any WG21 papers by him, nor seeing him at any WG21 committee meeting. I have only been attending myself for a few years, however, so maybe he predates me. I would be highly surprised if anybody who had regularly attended and contributed to other people's papers would have the opinions he has, most of which seem to duplicate the echo chambers in certain parts of Slack and Reddit and other self selecting engineering groups on the internet. Well informed criticism of WG21 is perfectly valid, and probably shared by most WG21 participants in fact. But uninformed criticism based on grievances is not. Niall

Niall Douglas wrote:

Most libraries presented for standardisation ARE battle hardened libraries. However they were typically written for preceding C++ standards, and in outdated idioms and design patterns, and require modernisation which can involve substantial refactoring.

Maybe not most. It's no longer easy to give a single reason as to why the committee's output is what it is, as the submissions are of varying quality, philosophy, and origin; there's no single universal problem with them. Some of them come from big companies, are indeed totally battle-hardened, but reflect the monoculture of the company which does not correspond very well to the environment in which the median C++ programmer operates. Others are useful facilities in use in more than one relatively smaller company, battle-hardened, but pragmatic, prioritizing problem-solving over design elegance or avoidance of undefined behavior. And then we still have the "direct to video" libraries that haven't actually seen much practical use. In theory the committee should be that great place where people who value design elegance and lack of undefined behavior and specification imprecision meet the people who need to get their work done yesterday and the people who have a lot of experience with large scale deployment, but in a company culture that's not representative of the C++ community as a whole, and the end result is supposed to be the best of these worlds. But it isn't.

On 3/16/21 9:49 AM, Peter Dimov via Boost wrote:

Niall Douglas wrote:

...

Most libraries presented for standardisation ARE battle hardened libraries. However they were typically written for preceding C++ standards, and in outdated idioms and design patterns, and require modernisation which can involve substantial refactoring.

Maybe not most.

It's no longer easy to give a single reason as to why the committee's output is what it is, as the submissions are of varying quality, philosophy, and origin; there's no single universal problem with them.

Some of them come from big companies, are indeed totally battle-hardened, but reflect the monoculture of the company which does not correspond very well to the environment in which the median C++ programmer operates.

Others are useful facilities in use in more than one relatively smaller company, battle-hardened, but pragmatic, prioritizing problem-solving over design elegance or avoidance of undefined behavior.

And then we still have the "direct to video" libraries that haven't actually seen much practical use.

In theory the committee should be that great place where people who value design elegance and lack of undefined behavior and specification imprecision meet the people who need to get their work done yesterday and the people who have a lot of experience with large scale deployment, but in a company culture that's not representative of the C++ community as a whole, and the end result is supposed to be the best of these worlds.

But it isn't.

The idea that disappointment with the standards process more than one cause and different libraries disappoint for different reasons goes a long way to explain why we're having so much trouble suggesting improvements to the process. Robert Ramey

On Mon, Mar 15, 2021 at 2:38 PM Emil Dotchevski via Boost < boost@lists.boost.org> wrote:

On Mon, Mar 15, 2021 at 1:21 PM Niall Douglas via Boost < boost@lists.boost.org> wrote:

...

On 15/03/2021 19:01, Richard Hodges via Boost wrote:

...

I fully agree with regard to the committee. It has been nothing but a cause of frustration and anger for the community of developers who actually use C++ to get work done. I have the strong impression that very few on the committee ever produce anything of strategic value for their employers.

Disagree completely.

...

This is about as categorically untrue as any statement could be.

As a general rule, those who regularly attend WG21 meetings are responsible for enterprise level software, having in large part contributed to the design, implementation, and maintenance of those mission critical systems.

It's a mix of different kinds of responsibilities and experiences. Many committee members are implementers of compilers, tools, and standard libraries -- as is necessarily the case. Of course many of the implementers are also users at some level -- just typically not the 'average application developer'. Many, many participants in this list regularly participate in WG21 -- it's not simple to describe the participants and their motivations. At my day job I write enterprise applications in c++ and have for decades. My participation in WG21 is completely self funded and on my own time -- as are many other committee members. Do I think more companies that are simply 'users of c++' should sponsor committee participation -- yes I do, but I'm not holding my breath.

The committee seems to be concerned more with internal and external politics than with serving the community. If that wasn't true there would be ZERO library additions that haven't been battle hardened by being deployed and established themselves as the defacto standard already.

Unlike the boost review where there's 'a decider', the committee uses consensus. It's a much higher bar, as frankly, it should be. If even 1/3 of the committee doesn't agree on something it's unlikely to move forward. As for battle hardened, sometimes it's not quite so simple as sometimes language changes are needed or vendor support is needed. Every proposal gets vetted for usage experience and it's clear that without experience it's unlikely to go forward. Is the process perfect -- no. Will it make everyone, even the members happy -- no. Can it be improved -- surely -- but like many things in life it's not as simple as we'd like.

The only thing they should be doing is rubber-stamping libraries that are already the standard for doing something.

And if we 'just did that', things like generic programming wouldn't exist in c++. If the 'Roque Wave' container design was adopted in 1998 the world would be very different now.

Instead, it's like a giant tube for force feeding us what we don't want (or else we would have adopted it already). For our own good of course.

My honest suggestion is if your country has a national body -- get to know them and express your opinions about proposals to them so they can be reflected. And if you want one of those 'battle hardened' libraries adopted, that's fine -- you don't have to be a member of the committee to propose it. It will help your odds to get someone experienced with process to help -- because there isn't a rubber stamp -- stuff is vetted. Jeff