Re: [boost] [outcome] non-interface-related concerns

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-28 18:43:48

> I dispute all of the above assertions.  There is not evidence for them -
> how could there be as they are not true?  And even if they were true,
> they would in no way be an argument for the library, up ending boost via
> the inclusion of a single very small and simple library or anything else.

I find it astonishing how threatened some people are by a highly
non-intrusive internal implementation library which has no effect on:

1. The end user experience.

2. Any other Boost library.

3. Boost itself.

People are making mountains out of molehills. Nobody has given a single
technical reason why the presence of that internal implementation
library is a technical showstopper to anything except the maintainer's
maintenance burden, which is my problem, not yours.

I'll accept Bjorn's feedback that its unspecified nature makes it harder
to review implementation as part of review, but I genuinely thought
people would just run g++ -MM and get on with it.

> Although it's implicit in my comments, I'll be explicit about my
> suggestion:
> 
> a) submit outcome in a way that looks like the rest of boost libraries
> so it would be evaluated by the same criteria that other boost libraries
> are.

As Jon Kalb mentioned during CppChat only yesterday, there has been a
wholesale move away from libraries entering monolithic collections like
Boost in favour of people's own github repos where few end users find
them. And that has been a negative thing with regard to WG21
standardisation.

As I hinted at strongly in my technical description of boost-lite,
what's coming next is that libraries will join **multiple** collections
of standards aspiring C++ libraries. There are already mini-Boost's
popping up, most of them are individual github collections, but it won't
be long now - thanks to git and git submodules - that a C++ library will
become part of many collections simultaneously. All my libraries have
been written to be good neighbours to any other C++, and to be highly
flexible for end use cases. It's a huge value add for the burgeoning
ecosystem of next generation C++ libraries.

People don't want intrusive C++ libraries which **impose** foreign build
systems and command line tooling and configuration on end users any
more. They want libraries you can drop into your C++ as a git submodule
or a single file include and no faffing around needed. That's the future.

If Boost is unwilling to accept such good neighbour libraries as Outcome
is, then I feel very sorry about that. I have tried very hard to make
using Outcome a superb end user experience, and for some reason the
techniques I have employed scare some people here. A shame.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/