On 10/21/18 2:33 PM, Antony Polukhin via Boost wrote:

On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost wrote: <...>

...

Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.

+1.

I'm really interested in having all the C++2x prototypes in Boost. Looks like everyone would benefit from that. Is that a reasonable idea?

Boost now consists of >150 libraries, a number of them barely maintained. Who do you propose would maintain those additional projects ? I think before we can even think of an endeavour of that scale, we should fix the scalability issues we already have. Stefan -- ...ich hab' noch einen Koffer in Berlin...

On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:

On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost wrote: <...>

...

b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important.

Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost.

Hmmm - where is it? I'm aware of Boost Ranges but not of any other library which implements a similar facility.

Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place.

Right, I'm sure that boost would be willing to review any such libraries when they are submitted. Robert Ramey

On 10/21/18 3:54 PM, Robert Jones via Boost wrote:

On Sun, 21 Oct 2018 at 22:09, Robert Ramey via Boost wrote:

...

Hmmm - where is it? I'm aware of Boost Ranges but not of any other library which implements a similar facility.

Eric Niebler's range-v3 library, https://github.com/ericniebler/range-v3

I'm not intimately familiar with it, but I believe it's all Boost::Range V2 and then some.

Actually this is exactly what I was referring to with my point b) above. Eric is a highly respected Boost Developer (Boost.Xpressive, Boost.quickbook, and otherstuff etc.) After C++11 he got an opportunity to develop ranges under the auspices of the C++ standard committee. Many of us were disappointed that he didn't choose to do it under Boost. But of course it's his choice. But now Ranges may come as part of the standard in C++20. And then sometime after may be available when/if compiler vendors choose to implement their own version. All in all, the committed would have been able to spend time on other stuff which only they can do. And Boost would have had an modern ranges library years ago. Also Boost might have had a useful library based concepts system. Only now do we have a modern replacement for mpl - this would have happened years earlier. Compared to Boost, the C++ committee is an inferior organization to design and produce quality software. It's not that they don't have smart people, it's that the C++ committee structure is setup to define and approve standards - which is not the same as designing software. Robert Ramey

Regards

Rob.

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

On 10/22/18 11:53 AM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 3:33 AM

But now Ranges may come as part of the standard in C++20. And then sometime after may be available when/if compiler vendors choose to implement their own version. All in all, the committed would have been able to spend time on other stuff which only they can do.

They would still have had to spend the time on standardizing ranges-v3. I don't see how ranges-v3 being in boost instead of a stand-alone repo would have made any difference for standardization, unless you assume that it would have produced a much superior design.

Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.

Also, considering that the "actual" ranges library depends on concepts, I don't see how that work could have been done as part of a boost library which is commonly expected to work with a wide variety of compilers / compiler versions.

This is not quite true, in general. IIRC, when Hana was accepted, it was working only on some bleeding edge versions of gcc or clang, which were not even shipped in any distros at the time. Of course, Boost libraries strive for portability, but at the same time they are allowed to require a certain minimum C++ version. This is a per-library balance.

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 4:29 PM

On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:

...

On 10/22/18 11:53 AM, Mike Dev via Boost wrote:

...

Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.

Also it allows for evolution. Standardization does not. People complain about io streams being too .... But what would be involved in getting that fixed now? No one would invest the effort to get a "fixed" version through the standards committee.

I didn't say having existing practice isn't important. Actually I did quite the opposite (quoting myself):

The one thing I can say however is that for standardizing libraries, a production quality, cross-platform implementation (which may or may not be part of boost) is much more useful than a TS that doesn't get implemented by half of the toolchains.

What I do say however is that 1) having such a widely used implementation doesn't necessarily reduce the amount of work the committee has to do in order to standardize: Just have a look at the things from boost that got merged into the standard (or where the committee is currently trying to merge them). 2) in times where everyone can easily publish their library on github on the one hand and projects try to actively shed or avoid their dependency on boost, having your library distributed as part of boost is certainly not the only realistic way to get lots of usage feedback. Ranges-v3 in particular became quite well-known and popular in the c++ community and I believe the main hurdle to its wide adoption was the inability of MSVC to compile it - not that it wasn't part of Boost. Again, I absolutely don't want to deny the value having a library going through boost prior to standardization. I'm just not convinced, that it would have helped the standardization process if ranges where developed as part of boost. One general problems I see with standardizing existing practice btw: A new library designed for use in production rarely gets written against the latest version of the c++ standard. Once it is written it takes quite some time until it gets adoped widely and even longer until it really becomes established practice. So at the time where you start to work on standardization, the library is designed against a language that is probably 2-4 Standard revisions older than the one in which it will gets standardized. Depending on how much the language changed in between, and how much the library has evolved in the meantime you need to spend at least some effort (and sometimes considerable effort) to bring the design in line with modern language principles (Use std::chrono duration instead of ints, using string_view, . Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all. Mike

Robert Ramey

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

On Mon, Oct 22, 2018 at 8:27 PM Robert Ramey via Boost wrote:

On 10/22/18 10:13 AM, Mike Dev via Boost wrote:

...

Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all.

True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.

I believe that one of the original goals is to "standardize existing practice" and perhaps they shouldn't do that. One thing that they do which no one else can do is specify language syntax and semantics. Expanding too far beyond this essential function can compromise the successful accomplishment of that very function.

The problem is defining that "too far beyond this essential function". Is it unique_ptr? Ranges? 2D graphics? In my view, the following are good reasons/potential candidates: * Anything that is universally useful, i.e. repeated over and over in all projects with a similar implementation (e.g. containers, array, string, unique_ptr, regexp...), even if the standard one would not be perfect for all projects. * Anything that is "set in stone" or comes from other standards (e.g. math, chrono...). * Anything that requires or benefits from compiler support, i.e. anything that should be the responsibility of compiler writers, rather than third-party libraries which end up with a thousand #ifdefs (e.g. static_assert, contracts, stacktrace...) * ... Cheers, Miguel

I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].

I think there is widespread agreement that if we had a decent and universal package management solution, most of the standard library proposals before the committee would no longer be necessary. Interestingly, P1031 Low level file i/o and the Networking TS are not examples of those. Both require changes to the core language to work well. So I think for those two at least, they'd be before the committee no matter what. Niall

On 10/23/18 2:11 AM, degski via Boost wrote:

On Tue, 23 Oct 2018 at 10:44, Niall Douglas via Boost wrote:

...

Interestingly, P1031 Low level file i/o and the Networking TS are not examples of those. Both require changes to the core language to work well. So I think for those two at least, they'd be before the committee no matter what.

But maybe [some of those] TS's should be permanent fixtures, sort of like associated libraries (SAL) [with added support in the language where required, to accommodate those]. The 2D Graphics should be in there as well. Writing client/server applications and/or 2D games are not things everybody does, they should not be standard libraries. But there are more of course, f.e., a GUI lib and a Crypto lib.

I'm not sure what this says - but it might be on the right track. If doing a good job for something like network TS requires some changes in the core language, then maybe the committee should focus on just those "enabling" changes. This would permit the development of network libraries untethered by the standard. So the network TS would be more of a use case, example, case study or whatever. The same could be said for 2d graphics. Perhaps some core facilities need to be added. Example might be standardizing a low level interface to SIMD graphics processors. If so, these would be suitable scope for a C++ committee. At the same time, there are lot's of different visions for a 2d graphics package. Trying to sort through this and arrive at a consensus will just end up displeasing everyone. And the above arguments apply to other stuff. But this begs the question: C++ needs a robust and complete set of high quality libraries to continue to prosper - and where are these going to come from? My argument is that organizations such as Boost are the prime candidates to fulfill this role. But in order to do so, things have to evolve. Boost is fine as far as it goes. But thinking about the future we need to address some things: a) as Nail as mentioned - an effective deployment strategy for C++ components. Given the nature of C++, binary API, tons of build options, lack of standard definition for things like visibility, runtime loaded code, etc. This is a very, very, very difficult problem in design and implementation. It's not going to be resolved by some committee with 100 people on it. Maybe, some genius will come of the woodwork and 100 people can agree - this is a big improvement. That's what I'm aiming for with "Call for Submissions - CMake for Boost". yeah, it's a crap shoot - albeit one with little downside. b) Part of this has to be finding ways to improve component reliability, ease of use, transparency/verifiability, and other measures of quality. For some reason, most programmers don't see any problem here. Personally I don't understand why - maybe it's just me. c) The above two are really about making components "composable". This a key strength/feature of C++. c) Drawing more people into the "monastic order" that is Boost. Boost is too hard to be a part of (though as far as I know there is no current celibacy requirement, but a CoC could change that). A lot of this can be addressed by addressing the above points. I see a huge vacuum crying to be filled and Boost is in an ideal position to fill it. Robert Ramey

degski

V V tor., 23. okt. 2018 ob 10:44 je oseba Niall Douglas via Boost < boost@lists.boost.org> napisala:

...

I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].

For the past 8 years I'm using ASIO (and now Beast on top of it) to crate GUIs as I already know web development and certainly don't feel like bothering with either platform specific GUI stuff or heavy weight frameworks such as Qt, WxWidgets,... Especially because web has HTML5 with all the JavaScript libraries for manipulating graphics already in place. So from my point of view Networking TS covers a big chunk of my inter process communication and GUI implementation (in both cases localhost and remote) letting me ignore Apache/NginX, PHP, C# with its ASP.NET framework... You might argue that C++ is not the best tool for web dev (and I would disagree because I really hate the devops and dependency bloat that the alternatives bring to the table) but if you ignore the "which language to use" part you can see that web and GUI world is not a small portion of programming tasks and Networking TS covers it quite well for me as the basic layer. For me being a base layer for two very different things (networking and GUI) is something that most definitely belongs into the standard - especially since C++ standard is heavily lacking in those two departments.

I think there is widespread agreement that if we had a decent and universal package management solution, most of the standard library proposals before the committee would no longer be necessary.

Universal minus at least one... Since I had to fight the NuGet packaging manager in C# today (and have fought the Java maven dependency hell quite often in the past - different libraries requiring different versions of the same library that don't play nice with one another) I somehow still believe that package management solutions are still not developed enough to be really useful on the language level (rpm and deb repositories not included [meaning that they are useful] as those start to eat away your nerves only if you are using an old/under-packaged Linux distribution or really need a custom build of a latest-latest library version) - so I'm for OS level package management (other people invest time to make the libraries play nicely together by using the same versions of one library on which other depend all the way) and don't see a universal C++ package management solution as being the thing that solves allot of library problems. Interestingly, P1031 Low level file i/o and the Networking TS are not

examples of those. Both require changes to the core language to work well. So I think for those two at least, they'd be before the committee no matter what.

+1 Now regarding the future and present of Boost I'm not a contributor/maintainer but am a long time user and before C++11 Boost libraries helped me allot. Unfortunately after C++11 release Boost started to annoy me as my compilers supported more and more of the standard implementations while Boost libraries kept their dependencies on boost versions of those same library parts. This becomes an annoyance and for me puts Boost not side by side with C++ STD library - instead it puts Boost more towards the Qt basket where you get the feeling that they want to be the be all end all framework that tries not to care about STD library as much as humanly possible (I could be wrong regarding both library bundles/frameworks but that's the feeling I got). As an outsider that probably even doesn't have enough C++ experience to contribute to Boost I see usefulness of Boost libraries such as Asio, Beast, DLL, Spirit/X3 that are not (yet) part of the standard but solve my problems - but on the other hand I dislike that DLL requires boost::filesystem (had some additional issues building Boost because of that dependency and also had to convert to std::filesystem to boost::filesystem in the code) and even submitted a patch for Beast so that I don't need to bother with boost::string_veiw and may instead use std::string_view. So from one perspective I like Boost as a location where I know I'll find quality libraries that will solve my problems but from the other that's the most that I see in current Boost as I don't have a problem using fmt [1] https://github.com/fmtlib/fmt library that is not in Boost (but I'm glad that it's trying to get standardized - at least in part). So to sum up: For me as a Boost library user Boost is a library hub that no longer works with C++ STD library but instead tries to compete against it as a Boost-STD library - so just another competitive framework. From my point of view Boost would become once again a C++ STD addition if it would contain libraries that are missing from the (latest?) standard and would use C++ STD parts wherever possible - C++ STD for long term stability, Boost for innovation and complementing the standard instead of trying to support N previous standards (or by being packaged differently for each C++ standard - only libraries that are missing from that standard and using boost substitutes only if they are missing in that standard version). I know that that is an awful lot of work but my guess would be that these are one of the rare options for Boost to continue to be C++ STD complementary bunch of libraries that push the standard forward instead of being just another "I work alone" blob of libraries that are splitting C++ codebases and being better-quality-C++-only-github-2 (nothing wrong with that but a different direction to pre C++11 Boost). On the other hand the only way I'd see Boost as a better place for currently proposed C++ libraries for standardization would be if C++ standard would say something like "C++ compiler is compliant to standard X only if Boost libraries X, Y, Z... are shipped with it in a working state" - and until then I prefer libraries migrating slowly from Boost into the standard. Just my two (probably useless) cents. Regards, Domen https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon Virus-free. www.avast.com https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Tue, Oct 23, 2018 at 2:36 AM degski via Boost wrote:

Well, in respect of the 2D Graphics proposal(s), I don't get it. There is a perfectly good (C++, cross platform, mature) 2D Framework [SFML] available, which seems to have been discarded from the block. No, instead we're gonna get [probably] some poofed up C thingy, which does not even allow you to write that little 2D Game [because we need a mouse, a window, touch, sound (formats), image formats, etc etc]. I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].

FYI, the SDL2 backend is now merged into the ‘master’ repo (of https://github.com/cpp-io2d/P0267_RefImpl). To use it, io2d needs to be compiled with the CMake flag, -DIO2D_DEFAULT=CAIRO_SDL2 --charley

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 8:27 PM

[...]

I'm arguing that the C++ standardization process is not useful for most C++ libraries.

True, but I don't see the problem. Most libraries never aspire to get standardized anyway.

The committee can't handle it. This is pretty much a demonstrable fact as far as I'm concerned. (I realize that people will disagree with this premise). So this leaves a vacuum which organizations such a Boost can/should fill.

Why does boost have to define its role in terms of its relation to the standardization process? Can't it just be a collection of well designed and well maintained open source libraries? Actually I'd like to see much more higher level libraries such as Beast in boost than the next compiler torture test (of course that would require someone writing, submitting and maintaining such libraries). Not sure if we have a violent agreement here without recognizing it.

...

. Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all.

True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.

I disagree. The c++ committee doesn't approve code either and the interface properties (APIs and ABIs in programming language speak) is exactly what the USB or WiFi standards define, just like the c++ standard defines interfaces. Anyway, let's keep this about boost and not the scope of the standardization committee. Mike

On 22.10.18 16:28, Robert Ramey via Boost wrote:

On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:

...

On 10/22/18 11:53 AM, Mike Dev via Boost wrote:

...

Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.

Also it allows for evolution.  Standardization does not.

There is deprecation in the standard if I am not mistaken. Removal is also up to compiler vendors as we saw not so long ago with VS2017. There is a bit a deprecation in boost, barely removal. If we want higher velocity in boost with the same energy/effort, we should reduce the mass. It is as simple as that. Raffi

On 10/22/18 1:53 AM, Mike Dev via Boost wrote:

...

-----Original Message----- From: Boost On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 3:33 AM

But now Ranges may come as part of the standard in C++20. And then sometime after may be available when/if compiler vendors choose to implement their own version. All in all, the committed would have been able to spend time on other stuff which only they can do.

They would still have had to spend the time on standardizing ranges-v3.

My point is that complex libraries such as ranges, networking, etc. don't belong in the standard at all. So in my world, the committee would spend zero time on these things - thus making available time on those things that only a standards committee can do.

I don't see how ranges-v3 being in boost instead of a stand-alone repo would have made any difference for standardization, unless you assume that it would have produced a much superior design.

Hmmm - the question posed really is whether Boost adds any value at all. That is, if a boost library is equivalent to any other library on github, then what's the point of Boost. This is actually the fundamental question that Boost has to face today.

Also, considering that the "actual" ranges library depends on concepts,

I'm not sure that it necessarily depends on concepts. But even if it does, Eric implemented his own library based version of concepts. Paul Fulks was inspired by that to propose such a library for boost which failed to pass review.

I don't see how that work could have been done as part of a boost library which is commonly expected to work with a wide variety of compilers / compiler versions.

I believe that Eric's and Pauls were both portable.

...

Compared to Boost, the C++ committee is an inferior organization to design and produce quality software.

Maybe I'm getting this wrong, but I don't see Boost designing or producing any software. I see some individuals producing and maintaining great libraries (certainly in part due to feedback from other boost members) that may or may not get accepted into boost.

Right. The only software actually designed and produced by Boost are the Boost building and testing tools. BTW - how's that working out?

The one thing I can say however is that for standardizing libraries, a production quality, cross-platform implementation (which may or may not be part of boost) is much more useful than a TS that doesn't get implemented by half of the toolchains.

That's it - the need is for high quality software components produced in a timely manner. I don't believe the standards committee can accomplish this goal. Robert Ramey

Best

Mike

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

On Wed, 24 Oct 2018 at 00:41, Raffi Enficiaud via Boost wrote:

I would make an effort to end the life of some libraries, rather than ending the life of boost or their maintainers. Boost should accept it successes and its failures.

- Is boost.test a success? I think it is, I am biased though. I would love to drop support for C++03 to get rid of all the intra-library dependencies that are polluting the usability.

- Is uBlas a success? If we get things done to accelerate, certainly. Otherwise I will just use Eigen as before.

- Is GIL a success? [...]

Please, present a definition of success or failure as basis to qualify a library for removal from Boost. FYI, GIL has been abandoned, but thanks to Stefan Seefeld, who joined long lonely wolf of GIL, Christian Henning, it's maintenance has been reactivated. A couple of months ago, I joined the efforts myself, as a long time GIL user. GitHub spits around quarter of million of C++ files referring to `boost::gil`, there some larger projects that use it (I know of TuttleOFX, K-3D). I do think that Boost has become overweight and must gain some lean working mass sooner than later. GIL still directly depends on (too) many libraries: libs/bind libs/concept_check libs/config libs/core libs/crc libs/filesystem libs/function libs/integer libs/iterator libs/lambda libs/mpl libs/numeric/conversion libs/preprocessor libs/static_assert libs/test libs/type_traits (We are working on cutting the list down and I have personally planned lots of refactoring in this area - if only there was 48/7 not 24/7.) So, from my perspective, major advantage of having GIL in Boost is to keep life of GIL users and developers easier. For me personally, working on Boost.GIL rather than just GIL is also a great opportunity to hang out with super-brains of C++, listen, ask and learn from the community on ML-s, IRC or Slack. That is also a source of motivation to act in Boost areas beyond GIL. For some Boost.GIL may sound more prestigious than just GIL. Having said that, I'd like to see GIL as part of Boost, selfishly, at least for as long as I keep contributing to it. If, however, GIL is kicked out from Boost, it will not be the end of the world, neither for GIL nor for me personally as GIL user and maintainer. It would bring many challenges but also opportunities. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On Thu, 25 Oct 2018 at 00:43, Raffi Enficiaud via Boost wrote:

On 24.10.18 10:32, Mateusz Loskot via Boost wrote:

...

On Wed, 24 Oct 2018 at 00:41, Raffi Enficiaud via Boost wrote:

...

I would make an effort to end the life of some libraries, rather than ending the life of boost or their maintainers. Boost should accept it successes and its failures.

- Is boost.test a success? I think it is, I am biased though. I would love to drop support for C++03 to get rid of all the intra-library dependencies that are polluting the usability. [...]

Please, present a definition of success or failure as basis to qualify a library for removal from Boost.

That is exactly what I will *not* do, this is you to define the success of the library you maintain :) You know your users and the ecosystem around the library better than anyone else. [...] The point is: we should look at boost with fair criticism over the time and the success of the individual libraries. This success may be within boost, in the community created around that library, or anything else.

Clear. I agree with your point, taken. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Mike Dev wrote:

- Unnecessary dependencies. All the projects I'm working on nowadays are c++14 or even 17. Why the hell does the latest version of my preferred boost library X still have a dependency on boost library Y that has been merged into the standard since c++11 or been superseded by c++11 language feature? It just adds complexity to the build process, increases compile times and sometimes leads to subtle bugs. I'm paying (sometimes little sometimes heavily) for something I don't use/need (c++98 compatibility).

We've been over this a few times already. We can't simultaneously support C++03 and C++14 (without heroics) because these are ABI- and API-incompatible. If the library uses boost::function it works regardless of whether the user is on C++03 or on C++17; but if it switches to std::function automatically when available, then whenever the user's -std and the compiled Boost's -std differ, trouble ensues. We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)

-----Original Message----- From: Boost On Behalf Of Peter Dimov via Boost Sent: Wednesday, October 24, 2018 5:00 PM

Mike Dev wrote:

...

- Unnecessary dependencies. All the projects I'm working on nowadays are c++14 or even 17. Why the hell does the latest version of my preferred boost library X still have a dependency on boost library Y that has been merged into the standard since c++11 or been superseded by c++11 language feature? It just adds complexity to the build process, increases compile times and sometimes leads to subtle bugs. I'm paying (sometimes little sometimes heavily) for something I don't use/need (c++98 compatibility).

We've been over this a few times already. We can't simultaneously support C++03 and C++14 (without heroics) because these are ABI- and API-incompatible.

[...]

We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)

That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago). It either makes everything more complicated or it requires more dependencies and/or - in the worst case - leads to compile and/or run-time overhead, because an efficient c++11 language construct is emulated with some wicket macro/TMP-library solution (which are even more wicket in c++03) or we have additional conversions between boost types and std types. At the very least, it requires more test-effort, because you want to support the newer standards anyway. Before someone puts up a strawman: Of course that doesn't necessarily mean you should remove boost::X from your code if it provides other benefits (other than backwards compatibility) over std::X. And no, I'm also not suggesting to just drop a useless c++11 feature into your code just out of malice (but realistically, almost every c++03 boost library could either shed dependencies or improve the code by using c++11 features/types). I don't know what the majority of the boost user base needs and what your personal needs (as a maintainer and most likely user of your own library) are but I'm saying that, while maintaining backwards compatibility is probably important for some users, the side effects of it drive others (such as me) away from boost. It is a tradeoff and I'm certainly not so arrogant to believe that dropping backwards compat would be a net win for boost, but for me personally it would make boost more attractive again. Most other pieces of software can just bump their major version, when they think breaking backwards compat is beneficial, and the user can then either upgrade too or stick to the old version if he can't accommodate for the changes (yet). Often the old version still gets bugfix support for some time. But in boost the only way to create a v2 seems to be the introduction of a totally new library. I think that is at least one drawback of the common (non-modular) release model. Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits. Any other conformance bugs (e.g. two-phase lookup) have to be dealt with anyway and are orthogonal to the c++03 / c++11 question. Mike

Am 24.10.18 um 18:43 schrieb Peter Dimov via Boost:

Mike Dev wrote:

...

...

We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)

That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).

It's clear to all that everyone is held back by the inability to use C++11 things.

But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.

Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.

One thing I really do not understand is: Why should people use the newest and latest Boost version when they are stuck with an ancient compiler or code-base, which does not even support C++11? Do they really need the newest libraries from Boost? (Most of them require at least C++11 anyways.) Isn't it enough for them to stick to one Boost version that has all the needed Boost libraries and worked for a long time and be happy? OK, if they want to have the latest (security-)bugfixes, then they should get them as patches or as patch-releases of the same (old) version. My recommendation is therefore: 1. Announce that e.g. Boost 1.70 will be the last release that guarantees to compile with C++03 and that you will support it for some (longer) time by providing patch-releases (1.70.1, 1.70.2...), only including (security-related) bugfixes but no new features. (You need specific git-branches for this and they will differ over time from develop/master branch. 2. Create a new Boost 2.0 release (instead of Boost 1.71) which no longer guarantees to compile with C++03 and which guarantees to compile with at least C++11 (or better C++14). Then, for every new Boost 2.x version, you are free to remove as much C++03-only libraries or update other libraries to no longer support building with C++ standards older than the minimum required standard for Boost v2. 3. Some years later, you could create a new Boost 3.0 release which then might only guarantee to compile with at least C++17 (or C++20). And the latest Boost 2.x version will only receive (security-related) bugfixes. 4. Do the same every few years for new standards (if appropriate). You effectively would guarantee to support the latest C++ standard with the newest Boost version while gradually removing parts that no longer are required for compiling with that standard.

(Of course this just kicks the can a bit further down the road - we'll then need to pick between 11 and 14 as a default for g++ 5 and clang...)

...

Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits.

The point is that "C++11" is not useful as a requirement when it comes to MSVC, we need to pick a specific minimum version. 2013 is a good approximation of "C++11", I suppose.

I think, the best would be to make a hard cut. Find a good release (e.g. Boost 1.70) you might want to support for some time for "old" compilers while meanwhile go on with newest compilers that (fully) support the latest (minimum-)standard for your Boost Major-release. If e.g. only VS2017, GCC 7 and Clang 8 would fully support that minimum-standard, then these compiler versions will be the oldest compilers supported by the newer Boost versions. I really think at one time you have to drop backward-compatibility, at least for ancient compilers and standards. Just my 2ct, Deniz Bahadir

On 10/24/2018 2:12 PM, Deniz Bahadir via Boost wrote:

Am 24.10.18 um 18:43 schrieb Peter Dimov via Boost:

...

Mike Dev wrote:

...

...

We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)

That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).

It's clear to all that everyone is held back by the inability to use C++11 things.

But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.

Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.

One thing I really do not understand is:

Why should people use the newest and latest Boost version when they are stuck with an ancient compiler or code-base, which does not even support C++11? Do they really need the newest libraries from Boost? (Most of them require at least C++11 anyways.)

Isn't it enough for them to stick to one Boost version that has all the needed Boost libraries and worked for a long time and be happy? OK, if they want to have the latest (security-)bugfixes, then they should get them as patches or as patch-releases of the same (old) version.

My recommendation is therefore:

1. Announce that e.g. Boost 1.70 will be the last release that guarantees to compile with C++03 and that you will support it for some (longer) time by providing patch-releases (1.70.1, 1.70.2...), only including (security-related) bugfixes but no new features. (You need specific git-branches for this and they will differ over time from develop/master branch.

There is no such thing currently of a Boost release that is guaranteed to compile with C++03. It has been an impossibility once the first Boost library which needed C++11 on up was created. That was a long time ago.

On Wed, Oct 24, 2018, 21:30 Niall Douglas via Boost wrote:

...

But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.

As Beman suggested so many years ago now, it's long overdue for a separate Boost v2.x release which is shorn of the backwards compatibility and undermaintained libraries.

I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.

People can keep around Boost 1.x with the existing libraries as long as people want it. Let's just break free of the ancient cruft already.

And before anyone asks, it would be on each individual library maintainer to do the work to put their library into Boost 2.x.

I'm in. Let's do that. But let's change the namespace to avoid conflicts with Boost1, in case of some library would be included in both projects.

On Wed, 24 Oct 2018 at 20:31, Niall Douglas via Boost wrote:

...

But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.

As Beman suggested so many years ago now, it's long overdue for a separate Boost v2.x release which is shorn of the backwards compatibility and undermaintained libraries.

I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.

+1

People can keep around Boost 1.x with the existing libraries as long as people want it. Let's just break free of the ancient cruft already.

+1

And before anyone asks, it would be on each individual library maintainer to do the work to put their library into Boost 2.x. Which should be 100% cmake, incidentally.

+1 Let's leave Boost 1.x as is, as mixture of 03, 11, 14, etc. Let's revolutionarly reserve make Fosbury's flop reserving - Boost 17.x with `-std=c++17` as minimum - Boost 20.x with `-std=c++20` as minimum ... Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

Niall Douglas wrote:

I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.

Surveys also say that g++ jumped straight from 03 to 14, the latter now being default.

On 10/24/2018 12:43 PM, Peter Dimov via Boost wrote:

Mike Dev wrote:

...

...

We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)

That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).

It's clear to all that everyone is held back by the inability to use C++11 things.

But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.

Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.

I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ? I agree, and have agreed, that Boost should spend no resources testing anything which still supports C++03. I agree, and have agreed, that end-users should be told that any library which currently support C++03 may, without prior notice, choose to support only C++11 on up in its next release. I just don't understand why a library which does support C++03 is a liability to other libraries which support C++11 ? Now if you are saying that libraries which do support C++03, but which use Boost libraries rather than their C++11 equivalents, should change to support C++11 so that their C++11 equivalents are used instead, I can understand that argument, since that was what cxxd was largely about and sought to accomplish without forcing a C++03 library to specifically change to a C++11 on up library. So I can understand the perhaps more straightforward idea of forcing a C++03 to become a C++11 library and use the C++11 equivalent library rather than the Boost library.

On 10/24/2018 5:21 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ?

I don't know how to answer this, and I don't know how it relates to what I was saying.

What I was saying is this: the user, or someone acting on his behalf such as a package maintainer, types f.ex.

   b2 toolset=clang install

and obtains a prebuilt Boost.

Then the user types f.ex.

   clang++ -std=c++17 myapp.cpp -lboost_pumpkin

and expects it to work. If boost_pumpkin autodetects C++11/C++14/C++17 and changes its API to match, it doesn't work.

Is not this a user problem, irrelevant of cxxstd level ? The user is given a Boost package compiled with the default cxxstd level for clang and then attempts to use it imposing his own cxxstd level. I would expect disaster in any case except when the default cxxstd level matches what the user specifically uses, regardless of what those levels ( c++03, c++11, c++14, c++17, c++20 ) actually are. I can not imagine how this can be a Boost ( or any library ) problem as opposed to a user problem.

It doesn't because step 1 builds libboost_pumpkin.a with the default -std=c++03.

Same with g++ 5.

Not same with g++ 6 and above, whose default is C++14, but still possible if the library adapts to C++17 by using f.ex. <filesystem>.

On 10/24/2018 6:53 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

...

What I was saying is this: the user, or someone acting on his behalf such as a package maintainer, types f.ex.

     b2 toolset=clang install

and obtains a prebuilt Boost.

Then the user types f.ex.

     clang++ -std=c++17 myapp.cpp -lboost_pumpkin

and expects it to work. If boost_pumpkin autodetects C++11/C++14/C++17 > and changes its API to match, it doesn't work.

Is not this a user problem, irrelevant of cxxstd level ?

It is a user problem, but note that it doesn't happen if libraries don't change their API in response to the cxxstd level. That is, libraries that assume C++03 and use the Boost components instead of their standard equivalents don't suffer from this, it all works.

If we up the minimum requirement

What do you mean by the above ? Suppose you made the minimum requirement C++11, what would you expect a library to do to meet that requirement ? I think this is the gist of all the disagreements about what cxxstd Boost should support as a minimum.

these libraries could just unconditionally transition to the std components wholesale (again without adapting to cxxstd) and it will still work (provided that we either build with an intelligent post-03 default, or quit with an error when C++03 is assumed by omission as above, thereby forcing the user to choose a preferred post-03 cxxstd level.)

On 10/24/2018 7:49 PM, Peter Dimov via Boost wrote:

Edward Diener wrote:

...

...

If we up the minimum requirement

What do you mean by the above ?

We announce that Boost has a minimum requirement of such and so, and will no longer support platforms not meeting it starting with release 1.X.

...

Suppose you made the minimum requirement C++11, what would you expect a library to do to meet that requirement ?

The library doesn't meet the minimum requirement, the compiler does. The library may assume the minimum requirement.

As an example, if our minimum requirement implies a working std::function, Boost.Test may use std::function in its interface and implementation, unconditionally and without checking cxxstd or BOOST_NO_CXX11_HDR_FUNCTIONAL or whatever else, and its maintainers can in good conscience accept pull requests making use of other C++11 features whose availability is guaranteed by the minimum requirement.

Haven't we already basically agreed, going forward with Boost, that a library can use C++11 features and the C++11 Standard Library without informing end-users in advance that it is going to do so, if previously it supported C++03 ? If not, that was what I thought the previous long discussion about dropping support for C++03 was largely about. I do not think there is anything more that Boost can do to attempt to promote C++11 as the minimum standard it supports, at least at the level of each individual library. As far as Boost Test is concerned, or any other Boost library, I think it should use C++11 if it desires. If C++03 library depends on a library which has gone from C++03 to C++11 then that C++03 library is now a C++11 library as long as it maintains that dependency.

On 24.10.18 22:50, Edward Diener via Boost wrote:

On 10/24/2018 12:43 PM, Peter Dimov via Boost wrote:

...

<...>

I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ?

Technically everything is possible. It is just opposite to "practical" and redundant, and slows down development and adoption. - part of boost have redundancy with the C++ standard library. As a developer, I do not like having redundancy and I want the minimum set of dependencies, because otherwise my work gets harder. - this makes libraries artificially bigger than what they would be or need to be if I put the stdlib in the equation. Which in turn makes integration of those libraries way too difficult and lower the ratio pros vs. cons. Note that this is (a bit) orthogonal to modularity. Adding a layer of header switch/case is making the issue worse. The adoption of Boost was catalyzed by the almost standard installation of boost on their OS, because - among other things - boost was necessary in the past for doing decent C++, but this is not the case anymore. Better packaging solutions are not going to solve that neither, I still have redundancy and big fat libraries. Boost.test is a perfect example: it supports C++03 and C++11. Just compare it to the adoption of google test and catch. Those are so easy to integrate in any repository that "people" just do that. And this is not about the level of features each library brings that is the definitive game changer: simplicity of integration is a key component. I remember that the proposed solutions in this ML, if the maintainers were to drop C++03, would be to go through a formal review process of a "new" library, bringing Signal/SignalV2 as an example. This is far from ideal, especially this specific deprecation example of Signal last so many years. I remember also that some C++11 features were added to boost.test without conditional testing on the C++ standard level. This commit has received an incredible number of complains from this list, including the promoters of C++11 in this list. Those products are alive, but we constantly force them to look like the past. Any new C++ standard should give the opportunity to maintainers to update their library, immediately after the support is adopted on a minimal set of compilers, and without rebranding to boostv2 or boost.test v4. We see more and more "LTS" type of releases. Maybe we should think adopting this to give a sense of stability. Raffi

Ranges-v3 (the c++11 version with the library implementation of concepts) is certainly a nice library that can be used by more people but e.g. compile-times were a real bummer and it still doesn't compile on msvc.

Also quite frankly: Given that it is yet another library that emulates a native language concept with insanely complex TMP machinery, I'd hate to see that library as a dependency of other header-only boost libraries whose compile-times will then remain insanely high years after real concepts have entered the standard. And I'm not sure if anyone will want to spend the time to properly maintain it once Eric moves on.

You appear to be mistaken regarding a few facts. Firstly, there are now several Ranges implementations around, and I believe ALL of them compile, without hacks, on VS2017.9. Secondly the Standard C++ Foundation sponsored Eric to design and write Ranges v3 for the purpose of immediate standardisation. That makes it unique amongst all libraries entering the standard as far as I know. It was commissioned given Eric's unquestioned reputation in that space as the putative STL v2 (since rejected). Thirdly Eric is no longer the primary maintainer of Ranges v3, nor has been for at least a year or more now. He is wholly consumed with getting the thing through the committees which is extremely detailed, all-consuming work. I've sat in LEWG, it's like watching paint dry as Eric answers again and again the same questions raised again and again. Occasionally there is a nugget of gold in there, and it results in a fix avoiding a corner case problem, but for the most part Eric and Casey have thought through every design point and decision. It's just going through the motions to get the thing over to LWG. There are valid criticism of Ranges however. Firstly, even on a fully compliant compiler, they look to be much slower to compile when used in anger, and that's probably unavoidable without more powerful language abstractions. Secondly, optimisers currently are not well tuned for Ranges, and too easily give up which causes poor codegen. Thirdly, there are definitely problems at the intersection between other stuff and Ranges e.g. Eric wants lots more async and coroutines, and while I am not competent to speak on other intersections, in the area of file i/o I am very sure he is wrong on that, and indeed I dropped async file i/o entirely in P1031R1 after he couldn't give me a compelling use case to retain it. I will be starting work soon on the paper standardising support for next gen storage e.g. Samsung KV-SSD, and Ranges does not fit at all well with that either. Ranges may, or may not, have to be adjusted to cope. I have yet to discuss this with Eric, it'll be next year at earliest. So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not. Niall

On 10/24/18 11:26 AM, Niall Douglas via Boost wrote: <snip>

So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not.

A useful exposition of wow the sausage is made. This a perfect example of why expanding the committee's scope to design of complex libraries is not a great idea. It doesn't scale. Adding mroe committees, adding more members, etc. will only make the problem worse. The only hope is to carefully limit scope of the committee to what it is actually good at. It's not the language, it's not the committee, it's not the people on the committee. It's that they have chosen to expend their efforts on the wrong thing. Robert Ramey

Niall

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

On Mon, 22 Oct 2018 at 10:16, Antony Polukhin via Boost wrote:

Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.

+1 IOW, let's replace Review Manager with Review Arbiter, only called if necessary. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

On 10/22/18 1:14 AM, Antony Polukhin via Boost wrote:

On Mon, Oct 22, 2018, 00:09 Robert Ramey via Boost wrote:

...

On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:

...

On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost

<...>

...

Right, I'm sure that boost would be willing to review any such libraries when they are submitted.

I'm proposing to relax the review requirements for those libraries. Include them even if the Boost feedback was "need more work". Simplify the review process.

We already do this. Some libraries have been "accepted" with conditions which have entailed a long time - some times years to meet. The lastest instance is the safe numerics library. This was accepted. But the review revealed problems which took 18 months to fix (and still not quite done).

We should give users and library authors a simple way to meet and interact. Boost is a perfect platform for establishing existing practice and ensuring library quality.

I think we have this and I think it's the key feature of boost. Requirements (testing, docs, etc.) a review processes. No other option provides this.

Let's not loose it because of the exhausting review process that requires a lot of time and scares of some of the authors. If the library accepted into C++ or Library Fundamentals - then it was already reviewed.

Maybe the library interface, but certainly not the rest of it: code, docs, tests, etc. BTW, what would be the point of implementing a library accepted into C++ - Won't that be implemented by the vendor anyway?

Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.

If an author finds boost requirements to onerous, he should just upload it to github. He doesn't have to follow Boost at all. He can even get it reviewed by reddit/cpp/review - https://www.reddit.com/r/cpp_review/ . No need for Boost at all if it's to much of a problem. Personally, I think the requirements to be accepted into boost too loose and we should raise them to an even higher standard. Robert Ramey

On 10/22/18 01:14, Antony Polukhin via Boost wrote:

Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.

The review process is not a democracy vote. The review manager is *the* decision maker to include or not include a library. The review manager position is critical to the entire process. -- Michael Caisse Ciere Consulting ciere.com

On 10/22/18 1:49 AM, Niall Douglas via Boost wrote:

...

All one has to do to see this is look at the papers list for the San Diego meeting.  Also look at P0977r0.  Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO.

In fairness, this is because its champions refuse to split ASIO into the bit everybody agrees with - the synchronous API - from the bit which is dependent on stuff not finished i.e. the asynchronous API.

If its champions were willing to fold deadlines/timeouts into the synchronous API and leave off the asynchronous API for C++ 23, they could ship, now, for C++ 20. So in the end the lack of any Networking in C++ 20 is 100% down to its sponsors and champions, not the committee who have repeated pleaded - even formally by Direction itself (P0939) - to get Networking into C++ 20.

This is what I'm talking about. Design by the standards committee is not a good use of the committees time and resources. If they insist on mandating libraries (itself a bad idea), the should just stick to evaluation of existing libraries.

...

Of course the C++ committee won't address the situation.  Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling.  Wake up and smell the coffee people.  Learn to prioritize and limit the scope of your actions to that which only you can do.  This would be better for C++.  Do less - get more done!

You may not yet be aware that WG21 is launching lots of new SGs, and spitting LEWG into pre-LEWG and LEWG all as part of handling better the increased workload. Its scope has markedly increased from even a few weeks ago.

LOL - Right. This is what all organizations do when they are faced with the failure to accomplish their stated objectives. They add more objectives! The try to become too big to fail. Sears heads down the toilet and they ... buy Lands End. It's an all two familiar patter. What they need to do is cut scope back to something they can actually do a good job on.

And now to Antony ... On 21/10/2018 19:33, Antony Polukhin via Boost wrote:

...

Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost.

Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place.

Eric Niebler is on record saying the primary reason he didn't submit Ranges v3 to Boost was the documentation requirement, which was onerous.

So he couldn't meet the requirements of Boost so it went to the standard. Boost standards exceed those imposed by the committee! This is why Boost is more successful than the committee in promoting development of quality libraries.

My main blocker for finishing Outcome is having to rewrite the documentation yet again. Everything else was finished six months ago.

I've had a lot to say about documentation. My advice to you and others with this complaint is that you must be doing it wrong. If you're waiting until the end of the process to add documentation, you're missing out on getting a better design. Here is what I have to say on the subject: https://www.youtube.com/watch?v=YxmdCxX9dMk Just follow these instructions and you'll find documentation a joy to write and the quality of your libraries will be much improved. You'll also find the review process, be it at C++ committee or at Boost, much, much less onerous - almost a pleasure. And you'll find that the review itself will be much, much more helpful than you've found in the past.

If Boost could start leveraging its ample cash reserves to solve the documentation problem, that would solve the problem.

Hmmm - I'm not seeing how spending more money would change peoples way of going about it. It's not a technical problem.

So, specifically speaking, each year the Boost SC allocates a fixed chunk of cash for documenting some reference library implementation of an approved upcoming C++ standard library. A popularity vote is held by Boost on which of the choices should win this. The winner has professional technical writers hired to write the documentation. The finished result appears on boost-dev for a mini-review. If approved, it enters Boost.

It would be free and alot easier if people just spent a little time learning how to do it properly.

...

Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.

I'd strongly oppose this, except where a review manager can be substituted by WG21 having formally decided to standardise a library.

Hmm - once a library is standardized, I believe that vendors are required to provide it so that their compiler is considered "conforming". BTW - how a compile with easily demonstrable bugs are now considered "conforming" is beyond me.

I appreciate lack of review managers gates the number of new libraries in Boost [1].

But, to be blunt, Boost is about *popular* libraries. If a library can't find a review manager, not enough enough of an itch is there to be scratched. That's the whole point of having review managers, to filter out too-niche libraries.

Personally, I've got no problem with "too niche" libraries. You're right they might have to scrounge around for a review manager. But as you note this is not a big problem.

[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.

If Boost were able to support modular deployment, this problem would go away. That is, if a library weren't being used, no one would download it and it wouldn't matter. Robert Ramey

...

[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.

Could you be more specific? Which libraries need attention?

Oh I've been quite specific in the past. I've given up trying.

If you want to reply directly I can work with the CMT to assess. Issues like this need to be brought up on the mailing list if folks thing something is being neglected.

A long time ago I made a list of Boost libraries ordered by the number of open, unresolved issues weighted by their age squared. The library which comes top of that list nobody would say isn't maintained, but the next few are very likely candidates for expunge. They don't have a maintainer, have long standing severe bugs which ruin productivity for their users, and worst of all, *do not advertise their low quality* in their documentation. They are also not core libraries, so removing them won't break other Boost libraries. Me personally, for each library without a maintainer I'd print a box at the top of every page in their documentation showing how many open bugs there are, and the average age of that open bug. Plus a wee note asking for somebody to step up to take over as maintainer. That means Boost stops lying to its user base wrt to its patchy quality.

We do have some procedures for dealing with this. I know we need to find new homes for libraries that Beman was maintaining.

Somebody, not me, ought to make a Boost.Filesystem v4 written using LLFIO. It would be an enormous improvement on STL <filesystem>, and would be the basis for the future reform of STL <filesystem>, which has a lot of problems.

We're removing Boost.Signals(v1) in 1.69.0. It was deprecated for.. a long time. (too long...)

My personal biggest bugbear is Boost.Iostreams. It should have been deprecated years ago. And I keep answering questions by perplexed users on StackOverflow who have sunk significant costs into adopting that library, and then find out to their horrible surprise that their work must be completely discarded and they have to start again with a non-fundamentally-broken alternative. Thankfully, we are on course to be able to offer in the C++ standard library a somewhat complete alternative to Boost.Iostreams by C++ 23, god willing. Niall