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

Subject: [boost] [outcome] non-interface-related concerns
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-26 14:14:50

The  discussion mostly revolves around the design of the interface of
`outcome::expected` and even `std::expected`. My questions here are about
the way this library will be distributed to users. And I am uncomfortable
with the situation. I am not necessarily saying it is wrong, but I do not
understand what is going on here.

1. The current GitHub repository consists of sub-repos. Do you (Niall) plan
to have it like this when the library is accepted? Is it relevant?

2. This macro BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE, it
controls whether I use this "preprocessed" file versus if I use... what?
Normal header files? What is gained by this preprocessed file? Not having
to include more than one header, or something else? Can I get different
results when compiling with and without this macro?

3. I am recommended to use this macro BOOST_OUTCOME_V1_NAMESPACE. I am told
it has something to do with ABI stability? Can you elaborate on how this
guarantees ABI stability. Or is its purpose different?

I have a certain problem with understanding this philosophy. A couple of
days back, I reported the compilation failure in MinGW. I can see that the
issue (https://github.com/ned14/boost.outcome/issues/36) is reorted as
fixed in branch 'develop'. I would like to confirm that the bug is fixed. I
checkout branch develop. There is no branch develop for the sub-repos, so
what am I supposed to checkout, master, or some particular commit? I went
with master.

I do not understand a lot of CMake, but since it is a header-only library,
I assume that I can just #include the file "include/boost/outcome.hpp", and
my programs (compiled manually) should compile.

But the only change in the commit that was supposed to fix the bug, was in
a .cmake file, so I cannot see how it would help fix a header only library.
Also, would the fix be visible in a "precompiled" header, or normal
headres, or both?

I am not complaining about this particular fix. I would like to know how in
this system of mcros, sub-modules and preprocessed headers, I can figure
out what changes will be observed in my program, when I see a particular
change in git sub-repo.

Regards,
&rzej;