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

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Gottlob Frege (gottlobfrege_at_[hidden])
Date: 2017-06-03 21:59:57

For any library, I tend to lean towards more-complicated internals if
it means a less complicated external usage/API.  And I think you are
saying the same thing.  Great.

However, I think I am hearing concerns that the internals (and not
just code but the process behind it) may be so complicated, that there
are fears for those (besides you) that may need to dive into those
internals.  Either because they find some strange bug (maybe in an
unsupported compiler, etc) or in case you some day can no longer be
the maintainer, or whatever.
Or they just want to dive in to learn the code, which programmers often do.

More succinctly,
How hard would it be for me to become the maintainer of outcome?

How many non-outcome things would I need to understand?  Should it be
that hard? Shouldn't outcome be easy? And how important should this be
in a review?

I would appreciate answers to that from not just Niall, but anyone
else who understands the inner workings (as it is always hard for the
author to see their work from someone else's perspective).

P.S. the internals of many (most?) boost libraries are hard to
understand - too many macros, etc.  Is Outcome on the same level,
better? worse?  Even if it is on the same level of most of boost, I'm
sad :-(

Tony

On Sun, May 28, 2017 at 2:43 PM, Niall Douglas via Boost
<boost_at_[hidden]> wrote:
>> 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/
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost