Re: [boost] [review] outcome broken on MSVC, plus questions

Subject: Re: [boost] [review] outcome broken on MSVC, plus questions
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-27 20:07:57

> 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/