Re: [boost] What is this "Beman Project Development"?

On 10/05/2024 00:23, Ville Voutilainen wrote:

On Fri, 10 May 2024 at 02:11, Niall Douglas via Boost wrote:

...

Maybe you do genuinely believe the current process is optimal and cannot be improved upon.

But since you suggest I'm blind and suggest things like the quoted bit, which is just made up and not backed by anything I have ever said or done, have you ever considered the possibility that your views on such matters might be clouded by various proposals of yours not being "just waved through", and that somehow being anything but the fault of any problems in those proposals?

It is true I have been spectacularly unsuccessful at WG21. I have not affected one single word of normative text since I began attending meetings. The entire sum of my words affected would come from the next merge of the next C standard, where I have been far more effective with very considerably less work invested. Unsurprisingly, that's where I'll be moving to after the C 26 IS ships, as I'll have far more effect on the C++ standard from WG14 than I ever will from WG21. As to "just waved through" there is a point there. Everybody attending will have an opinion on the stuff they think was just waved through and not enough scrutiny was applied, and the stuff which got too much scrutiny and got dropped through attrition and exhaustion. I think that concentrates on the wrong thing, because all that is the result of the process chosen. We could choose a different process, and change that dynamic entirely. I definitely think far too much emphasis is placed by WG21 on library features which tick committee boxes such as "this is immediately compatible with the abstract machine" rather than what is actually useful to the ecosystem or end users. Most of my proposals which made no forward progress were due to demands that I first get improvements to the abstract machine through EWG to support things like memory mapped files, or virtual memory, or copy on write memory. What annoys me there is WG21 has the power to declare library APIs have magic powers. So just drizzle the magical powers over the APIs, draw a line under it, ship it. End users get portable memory mapped files with standardised semantics, the ecosystem benefits, everybody wins. WG21 wasn't willing to do that here, so I gave up. I have better uses of my time than fiddling with the abstract machine, for which by the way it was demanded that I had to fork a production compiler to implement the new abstract machine. I don't have that kind of free time, sorry. Of my two papers remaining, one has a pretty good chance of making it (path_view). The other has been repeatedly and publicly declared by multiple people as one of the finest library designs in C++ they've ever seen (std::error) but WG21 can't get over there being virtual functions in there. After three years of broken promises that WG21 will "do something" about ABI guarantees in libraries so the virtual functions can be replaced with something else, they just keep circling the drain about "virtual functions be bad". So maybe that will die too, we have three meetings left to find out. I'm of the opinion that carefully designed virtual functions are nothing like as bad as vast quantities of templates solidifying ABI. We continue to standardise vast tracts of new templates repeating the std::regex mistake. Yet a virtual function - they're somehow _worse_ - and I'm sorry, I just don't get it. Especially as there really is currently no better alternative to virtual functions for what they do, whereas most templates can be designed out entirely and WG21 could impose a "minimum possible templates" rule going forth if it chose. I've come to the conclusion that I'm the wrong type of engineer for WG21. Or, maybe better put, the kind of engineering I do does not fit what WG21 thinks is good engineering. A culture and fit problem. That's okay, I'll go where I'm more effective instead. Niall