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

Subject: Re: [boost] [outcome] non-interface-related concerns
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-27 15:04:41

2017-05-27 16:40 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >> 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.
>
> > 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.
>
> > 3. Niall does not want to maintain two nearly identical libraries.
>
> I still hold open the offer of a fully Boost flavoured edition of
> Outcome. I think it a mistake personally, but the offer is there. I've
> given up on trying to instil awareness of the end user experience of
> Boost into people on boost-dev.
>
> >> Mingw is not a regularly tested platform, and hence is not advertised on
> >> the documented compiler support page. Last time I tested it was well
> >> before Christmas.
> >>
> >
> > Hold on. This is the page you are referring to:
> > https://ned14.github.io/boost.outcome/prerequisites.html
> >
> > It says:
> >
> >> Outcome is a header only C++ 14 library known to work on these compilers
> >> or better:
> >>
> >>    - clang 3.5 (LLVM)
> >>    - clang 3.7 (with Microsoft Codegen)
> >>    - GCC 5.4
> >>    - VS2015 Update 2
> >>    - Xcode 7.3
> >>
> > It does not mention explicitly that it does not support MinGW. Now,
> MinGW,
> > according to my knowledge, is not a compiler but a platform on which a
> > compiler works. On MinGW I am using compiler GCC 6.3.0, and this compiler
> > is supported (Or not? -- you are ony mentioning GCC 5.4). This has been
> > always my understanding of what MinGW is.
>
> That's a very fair observation. I have updated develop branch to
> indicate what compiler-platform combos meant.
>
> >> It's working on develop branch for me with my mingw-w64, but it's not
> >> for you with your version. Problems like these are exactly why I don't
> >> support mingw. People ought to use MSVC or winclang on Windows, those
> >> work much more reliably. If people really need a POSIX-y environment,
> >> Windows can now run Linux binaries very well, even from Win32.
> >
> > Your decision to simply refuse to support some platform, well.., bothers
> > me. I understand that you do not have access to different
> compier/platform
> > versions, and that makes looking for bugs quite a burden. But it was my
> > understanding that this is how library maintainance works in Boost. You
> > have the test matrix, where people offer to test your library on
> > compilers/platforms you have never thought of, and you get the required
> > feedback. Can you be persuaded to a conditional agreement: if Outcome
> gets
> > accepted into Boost, you extend the range of supported compilers.
>
> It costs time and money to support platforms you don't personally use,
> and I have found an eager approach to deprecating and desupporting open
> source code I no longer personally use to be the only viable approach
> for my very limited free time. Once you're been supplying open source to
> people for twenty years as I have, it's the only feasible attitude to
> take. It also lets end users either move on to alternatives instead of
> being strung along waiting for fixes to software I won't be regularly
> updating any more, or else employ me to fix things for them if their
> need is urgent.
>
> I aim to support the most common 98% of users in my open source. If
> others wish to maintain my code on their niche
> platform/compiler/architecture, I will accept patches from them
> maintaining that support, and I'll try not to gratuitously break their
> contributed code. But I won't be doing it myself. I think supporting the
> top 98% of the most common environments is more than plenty.
>

That sounds fair.

>
> And I would add that Boost libraries only need to demonstrate a
> portability requirement. That falls very far short of endless and
> permanent support of niche, and often broken, toolchains.
>
> > Macros other than #include ? Usually you need macros to do things in a
> > different way based on platform, but the precompiled heder does not know
> > what platform it will be used on, so I wonder what macros you mean.
>
> Quite a bit of code is auto generated using preprocessor
> metaprogramming. All the ABI and namespace versioning stuff, for example.
>
> The partial preprocess step executes all the metaprogramming at build
> time and I commit to git an expanded edition without the preprocessor
> metaprogramming. When you #include Outcome, your compiler only needs to
> preprocess platform specific #if branches. It is very little work to do,
> and hence runs about a half second quicker.
>
> >> 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.
>

Will you stabilise v1 in the first official release of official
Boost.Outcome.
Or in other words, my expectation is that when I download the official
Boost release I will be using `boost::outcome::v1`. Do you commit to this?

>
> That way end users, who will tend to return outcomes a lot from public
> extern functions, will know for a fact that upgrading Outcome does not
> force a complete rebuild of all shared libraries.
>