Re: [boost] The future and present of Boost

Subject: Re: [boost] The future and present of Boost
From: Miguel Ojeda (miguel.ojeda.sandonis_at_[hidden])
Date: 2018-10-23 08:06:56

On Mon, Oct 22, 2018 at 8:27 PM Robert Ramey via Boost
<boost_at_[hidden]> 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