Re: [boost] The future and present of Boost

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