Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Mike Dev (mike.dev_at_[hidden])
Date: 2018-10-22 17:13:44

> -----Original Message-----
> From: Boost <boost-bounces_at_[hidden]> 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