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 sounded reasonable. 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. Thanks