Subject: Re: [boost] Boost.Outcome review - First questions
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2017-05-21 22:23:07
On Sun, May 21, 2017 at 3:12 PM, Niall Douglas via Boost
> Both you and Vinnie have called Outcome "over engineered". I
> respectfully suggest neither of you understands the purpose of Outcome
> the **framework**
When I raised the issue of requiring C++14 you made a point about
handling obscure corner cases of exception safety and what not. Those
are not necessarily the choices I would have made but your rationale
What I consider "over-engineering" is monad_policy.ipp having macros
that are set before being including three times to generate the
source. It complicates the documentation toolchain as you well know,
it confuses Visual Studio's intellisense, discourages casual reading
of the source code, and presents an interesting challenge if the
debugger brings you to a source code line in that file ("which class
am I in again?). I would have just duplicated the source code with
whatever differences the macros produce.
The other thing I is the versioning namespace. It seems to me that a
library only needs to introduce a version namespace upon publishing a
second, incompatible interface. The initial version of a library can
omit it. The consequences of this versioning namespace can be seen in
Outcome's documentation. "v1xxx::" everywhere which is quite a blemish
and also not something a user should ever have to type or see.
Full disclosure: I have not delved deeply into the interface of
Outcome, and I have not used it yet. But I don't anticipate that
Outcome's interface will undergo change so significant that we need to
lay out mentally cumbersome infrastructure in advance of those
changes. Do you anticipate a need to support multiple incompatible API
versions of Outcome? If so, how soon? And why do we need this
infrastructure in the first version of Outcome?
With respect to the error handling, memory allocation, policy concept
in general I have no comment yet.