Still working on the review; I had the following questions while reading the threads:
1. Which versions of MSVC 2017 does boost-outcome not work on, right now?
b2 libs/afio/test works fine with VS2017. So it would seem that that ICE Vinnie encountered is some weird corner case nobody could have anticipated. As I mentioned, almost all of the development of Outcome was done on MSVC. It's very well tested on MSVC, and I've never seen anything like that ICE before.
2. According to the documentation, outcome and boost-outcome both require MSVC 2017, right? i.e. They do not support MSVC 2015 or lower?
Outcome requires a C++ 14 compiler, and VS2015 does not implement enough C++ 14. Very early editions of VS2017 used to ICE with Outcome, but Tongari (I think?) found a workaround which is still in the codebase. So even early editions of VS2017 should be fine. Microsoft have since fixed the ICE. Microsoft now run Outcome as part of the regular Visual Studio test and validation suite, and thus any further surprises ought to be caught by Microsoft before anyone notices in future compiler releases.
3. Is standalone outcome fine with MSVC2017, only boost-outcome that is broken? 3.1. If so, is it right that the boost-outcome repository is "generated" from the outcome repository? And is that the reason that boost-outcome is broken on MSVC 2017?
I haven't reduced the ICE to a minimal test case, so I cannot say. I will not have the time to do so before the review ends, either. Later this week I think. I get approx two hours of freedom per weekday, and none at the weekend. It makes things very slow going. In any case, this is a compiler bug affecting a very special corner use case, that of an empty main(). b2 libs/afio/test works correctly. I think that should be the measure.
4. Would you happen to know how does your outcome/result compare to Peter's outcome/result in variant2? (I saw you point out that Peter implemented expected, and then I saw he also had an outcome/result implementation in variant2).
If I remember correctly, Peter implemented the Expected as it was last May. Expected looks different now due to many changes by the LWG. There is a comparison of Outcome to current Expected in the FAQ.
4.1. What different compilers and standards does his support compared to yours? 4.2. What kind of code is generated from his implementation compared to yours?
You'd have to ask him on those. But I would be confident that Outcome has a much lower compile time load in exchange for using more layout space, something which I've empirically benchmarked as to be statistically insignificant so long as `sizeof(E)` is small. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/