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

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2017-05-28 00:55:05

> >> I have also received quite a bit of private email begging me to keep
> >> Outcome free of a hard Boost dependency if accepted. I have asked them
> >> to say this publicly here, but I would assume they cannot for some
> >> reason or other. Quite a few talked about how their multinational's
> >> processes would find a standalone Boost.Outcome much much easier to
> deal
> >> with than one with dependency on other Boost libraries. Some of those
> >> are household name multinationals, and what they report matches my
> >> experience at BlackBerry.
> >>
> >
> > This probably deserves a separate thread. My understanding is that we
> have
> > three expectations:
> >
> > 1. Boost developers do not want duplication in Boost.
> 
> Some Boost developers are ideologically and irrationally attached to
> "how things are done around here", yes.
> 
> I don't know about not wanting duplication in Boost. There is a ton of
> duplication in Boost. It's been waved through in peer review many times
> in the past.

This is not true. It was always the idea of Boost to create as little code
duplication as possible. Why do you think we have so many cross dependencies
between Boost libraries? And yes, it has happened, but it should never have
been intentionally waved through.

> > 2. Non-boost users of Outcome do not want a dependncy on Boost.
> 
> Actually there is overwhelming evidence that Boost **users** do not want
> a dependency on Boost. But I've been saying that for years now.

This is just BS, sorry. Boost users choose Boost because they realize that
reproducing Boost functionalities would cost them even more than to live
with the disadvantages of Boost, namely having to deal with dozens of
(partly incompatible) versions, an isolated and arcane build system,
insufficient protection from ABI differences between library nmodules which
share the same name, ... you name it.

> >> Whilst Outcome is in an unstable state, the actual namespace used is:
> >>
> >> namespace boost { namespace outcome { inline namespace v1_GITSHA { ...
> } }
> >> }
> >>
> >
> > This sounds like we are doing a formal review of a library in an
> unstable
> > state.
> 
> Ok, unstable ABI then. Right now I am not promising the ABI won't
> change. When I do promise that the ABI is written permanently into
> stone, you'll get your boost::outcome::v1 namespace, and per commit
> it'll be checked for breaking changes by the abi-compliance-checker.

Again, only half-way true. The _design_ of the whole library is changing
under our noses (not just parts of the implementation) while we're supposed
to make an educated decision whether this library is ready for Boost or not.
Once upon a time a Boost review was supposed to refer to a single fixed
source code version and not a moving target as it is for this library. The
decision whether somebody would like to see a library accepted into Boost or
not should not be based on wishful thinking (that the author will implement
things eventually) or on unsubstantiated promises.

Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu