Provides very lightweight outcome and result (non-Boost edition)

Suppose I am using third-party library which exposes result<T,E>from my own library which exposes result<T,F>.

outcome::result<T,E> lib_func() {
  ...
}

outcome::result <T,F> my_func() {
  TRY(v, lib_func());
  ...
}

How can I provide a conversion from E to F when using TRY (I cannot add conversion operator into E, because it is a third-party component) ?

Hi!

I've added basic Conan support for Outcome, there are some issues left:

• Do we want to build unit tests inconditionally? (gcc 7.2 crashed on my Debian)
• I'm only packaging the single-header, since QuickCppLib is not installed by ninja install.

I didn't want to change the CMakeLists.txt before having your feedback, let me know if you want to support more than the single-header.

I haven't gone through the entire documentation for now but I'm fairly confident that this is either missing from the documentation or placed in a hard to find location...

From what I could gather from the tutorial the main reason for the existence of both result<T, EC> and outcome<T, EC, EP> is that with:

• result<T, EC>: the author of the function expects the user to either handle the error at the call site, determine that the error can be propagated upwards without the loss of information (example returning the result one level up will not confuse the user of that function which file failed to open as there is only one file being opened in the propagating function) or repackage the error to before returning the result/throwing an exception to something that is relevant to the callee (this is the usual case with low level errors such as opening files)

• outcome<T, EC, EP>: the author of the function expects the error to be specific enough to be relevant even if it is not handled directly at the call site (example of this would be that XML validation failed due to missing schema file xyz, due to error on line x, node referred to by the XPath is missing in the XML... where you in most cases don't need to add additional data to the exception to be understandable by the upper levels - for example by the roll-back-transaction-and-log-the-error-before-continuing-with-processing-of-the-next-package somewhere at the top of the callstack)

Since the distinction and the reason for the relevance of why both exist and where each should be used is important I'd add such an example towards the beginning of the documentation (and maybe a reference link to the section also at the beginning of the tutorial and the FAQ section). Maybe this should be added to the "Decision matrix" section (which should probably be renamed to "When to use result/outcome/exceptions" or something similar as "Decision matrix" was far from the first link that I've clicked on due to the current name...).

https://ned14.github.io/outcome/tutorial/result/

enum class ConversionErrc
{
  EmptyString = 1, // 0 is never an error
  IllegalChar = 2,
  TooLong     = 3,
};

https://ned14.github.io/outcome/tutorial/default-actions/enums/

  enum class err
  {
    success,   // REMEMBER it is best practice to always put "success"
    failure1,  // with value 0 as your first item in any error code
    failure2   // enum, even if you never use it.
  };

These both prescribe that 0 shouldn't be an error, but one does it with adding a success and another by starting the errors at 1. These are subtly different, especially if you want to exhaustively check for errors. To me, if it's used within result<t>, the success case is redundant in the enum class. I think it would be better for outcome to have a single prescribed way in the docs to help new users.

Should these docs be made more consistent with one another?

It would be very helpful to have some short documentation on how to use basic_result<> / basic_outcome<>. It's not the common case, so I think it could go in an appendix. I'd be happy to contribute something, but I'm not sure how to figure out how to use it other than looking at the code.

For example, it seems to need a NoValuePolicy, but I don't see where it's documented what to pass to that.

Here's an inconsistency between the std and your version.

#include <cstdlib>
#include <iostream>
#include <future>
#include <boost/outcome/future.hpp>

namespace lw = boost::outcome::lightweight_futures;

int main(int argc, char *argv[])
{
    try
    {
        lw::promise<int> p;
        //std::promise<int> p;
        p.get_future();
        p.set_value(1);
        std::cout << "done\n";
    }
    catch (std::exception& e)
    {
        std::cout << e.what() << "\n";
    }

    return EXIT_SUCCESS;
}

The std version prints done, but the lw version throws an exception no state.

Is the inconsistency by design or is it a bug?

The following code fails with the current master:

constexpr outcome::experimental::status_result<int> test() {
    return outcome::success(42);
}

with an error along the lines of

<source>: In function 'constexpr outcome_v2_35644f5c::experimental::status_result<int> test()':
<source>:6:53: error: invalid return type 'outcome_v2_35644f5c::experimental::status_result<int>' {aka 'outcome_v2_35644f5c::basic_result<int, system_error2::errored_status_code<system_error2::erased<long int> >, outcome_v2_35644f5c::experimental::policy::status_code_throw<int, system_error2::errored_status_code<system_error2::erased<long int> >, void> >'} of 'constexpr' function 'constexpr outcome_v2_35644f5c::experimental::status_result<int> test()'
    6 | constexpr outcome::experimental::status_result<int> test() {
      |                                                     ^~~~
In file included from <source>:2:
outcome-experimental.hpp:4145:25: note: 'outcome_v2_35644f5c::basic_result<int, system_error2::errored_status_code<...>' is not literal because:
 4145 | class OUTCOME_NODISCARD basic_result : public detail::basic_result_final<R, S, NoValuePolicy>
      |                         ^~~~~~~~~~~~
outcome-experimental.hpp:4145:25: note:   'outcome_v2_35644f5c::basic_result<int, system_error2::errored_status_code<...>' has a non-trivial destructor
Compiler returned: 1

(check godbolt).

I believe that did work before - tough I'm not 100 % sure. Any thoughts?

Fixable by me:

• [x] On the landing page there are several undocumented macros listed, which are presumably implementation details. (Probably already covered by #75.)
• [x] The file content summary at the top of each page includes several detail #include lines that are probably not especially interesting to readers.
• [x] The same also shows some quite lengthy noexcept expressions. Perhaps this can be elided to just noexcept(...) at the top and elaborated in the specific method detail further down?
• [x] It is unclear where no_exception_type would be used. Perhaps this is explained elsewhere?
• [x] In class outcome under "Comparison operators" appear two lines using 'hidden', which seem peculiar. A parsing artifact?
• [x] outcome is declared as outcome<R,S,P> but its description refers to outcome<T, E, P> instead, which might be confusing. Also neither is actually true since it ignores the NoValuePolicy.
• [x] rebind does not specify a type for NoValuePolicy, which seems like some kind of error; either there's a default parameter which is being hidden or this shouldn't compile.
• [x] The description for outcome goes on to mention the policy behaviours in terms of various traits; while the implementation is presumably obvious I couldn't find where trait::* are documented (it would be nice if there were links). Also, it seems perhaps a little naming inconsistency between the std:: traits that have _v suffixes and the traits:: traits that don't.
• [ ] The description of policy behaviour here seems a bit mixed up between how it selects the default policy based on the type parameters and how a policy (whether selected explicitly or by default) then behaves under particular conditions. These should probably be split into two separate sections for clarity.
• [x] NoValuePolicy has a tiny subheading "Template parameters" by itself, which is followed by larger headings for the other template parameters, which is both out of order and hierarchically confused.
• [x] Static template traits appear to be documented as an "unexposed entity", which seems like a peculiar wording.
• [x] There always seems to be unnecessarily large whitespace between a heading and the code block immediately following it.
• [x] In the All Narrow policy, wide_exception_check is described as not narrow?
• [ ] Why are bad_result_access and bad_outcome_access unrelated exceptions?

I didn't have much time to look at it so this was focused mainly on the outcome page and I've only just skimmed the rest. But hopefully it helps. 😁

Standardese issues (to be copied to #75)

• [ ] is_outcome_v is missing some whitespace (either space or newline) following the template declaration. This appears to be a general issue for all static or constexpr template values.
• [x] On the success/failure page, near the documentation for success_type/failure_type etc, the structure itself and its contained members have the same heading level, which is hierarchically confused and makes reading it harder. Presumably it makes slightly more sense if you arrive there from an earlier hyperlink and then jump back after reading just one thing, but if you are scrolling down the page it's confusing.
• [x] The numbering in this section keeps restarting from 1, presumably due to confusion with the nested bullets.

This may be kind of silly but during my work on #198 I found myself wanting a co_return-flavored version of BOOST_OUTCOME_TRY. Do you think it would make sense to add something like that either to try.hpp or the ASIO recipe?

Looking at the implementation, specifically

#define OUTCOME_TRYV2(unique, ...)                                                                                                                                                                                                                                                                                             \
  auto && (unique) = (__VA_ARGS__);                                                                                                                                                                                                                                                                                            \
  if(!OUTCOME_V2_NAMESPACE::try_operation_has_value(unique))                                                                                                                                                                                                                                                                   \
return OUTCOME_V2_NAMESPACE::try_operation_return_as(static_cast<decltype(unique) &&>(unique))

it seems we could do something like

#define OUTCOME_TRYV2(unique, return_keyword, ...)                                                                                                                                                                                                                                                                                             \
  auto && (unique) = (__VA_ARGS__);                                                                                                                                                                                                                                                                                            \
  if(!OUTCOME_V2_NAMESPACE::try_operation_has_value(unique))                                                                                                                                                                                                                                                                   \
return_keyword OUTCOME_V2_NAMESPACE::try_operation_return_as(static_cast<decltype(unique) &&>(unique))

and then generate implementations for return and co_return.

Again this may be a bit silly as it could involve muddying up try.hpp and landing us with some distasteful macro name like OUTCOME_CO_TRY, but I thought I'd mention it all the same.

The following fails to compile with quite a long error message:

#include "outcome.hpp"
namespace out = OUTCOME_V2_NAMESPACE;

out::result<int, int> fun()
{
    return out::success(3);
}

I realize that using result<T, T> is fishy, but you seem to support it: I do not get any error when only declaring this function. Also, when I initialize the object as above, you seem to have sufficient information to know which int I want to initialize.

Maybe this is just a constructor overload missing?

When an xvalue reference to temporary is passed to TRYX it creates a dangling reference at auto&& unique = (__VA_ARGS__); as the temporary is destroyed at the semicolon and lifetime extension does not apply.

I'm trying to setup CI for the Boost superproject, and the Windows CMake tests are failing because of Outcome under both windows-2019 and windows-2022 images. I can replicate the same errors using b2, so the issue isn't CMake-specific. b2 toolset=msvc-14.2 fails with

compile-c-c++ ..\..\bin.v2\libs\outcome\test\hooks.test\msvc-14.2\debug\threading-multi\tests\hooks.obj
hooks.cpp
test\tests\hooks.cpp(73): error C2280: 'boost::outcome_v2::basic_result<int,hook_test::error_code,boost::outcome_v2::policy::exception_ptr_rethrow<R,S,void>>::basic_result<int,void>(T &&,boost::outcome_v2::basic_result<R,S,boost::outcome_v2::policy::exception_ptr_rethrow<T,S,void>>::implicit_constructors_disabled_tag)': attempting to reference a deleted function
        with
        [
            R=int,
            S=hook_test::error_code,
            T=int
        ]

and

compile-c-c++ ..\..\bin.v2\libs\outcome\test\expected-pass.test\msvc-14.2\debug\threading-multi\expected-pass.obj
expected-pass.cpp
test\expected-pass.cpp(592): error C2664: 'stde::expected<int,std::exception_ptr>::expected(const boost::outcome_v2::success_type<void> &)': cannot convert argument 1 from 'boost::outcome_v2::failure_type<std::exception_ptr,void>' to 'const boost::outcome_v2::success_type<void> &'

and b2 toolset=msvc-14.3 fails with

compile-c-c++ ..\..\bin.v2\libs\outcome\test\expected-pass.test\msvc-14.3\debug\threading-multi\expected-pass.obj
expected-pass.cpp
test\expected-pass.cpp(592): error C2665: 'stde::expected<int,std::exception_ptr>::expected': none of the 4 overloads could convert all the argument types

If these failures are expected, would it be possible to #ifdef these tests out for MSVC?

Build error

[  2%] Building CXX object CMakeFiles/outcome_hl--comparison.dir/test/tests/comparison.cpp.o
In file included from /home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/config.hpp:35,
                 from /home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/coroutine_support.hpp:28,
                 from /home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome.hpp:26,
                 from /home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/comparison.cpp:29:
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/basic_outcome.hpp: In instantiation of 'constexpr bool outcome_v2::operator==(const outcome_v2::basic_result<R, S, T>&, const outcome_v2::basic_outcome<R, S, P, N>&) [with T = int; U = std::error_code; V = outcome_v2::policy::error_code_throw_as_system_error<int, std::error_code, void>; R = int; S = std::error_code; P = std::__exception_ptr::exception_ptr; N = outcome_v2::policy::error_code_throw_as_system_error<int, std::error_code, std::__exception_ptr::exception_ptr>]':
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/basic_outcome.hpp:1093:1:   recursively required from 'constexpr bool outcome_v2::operator==(const outcome_v2::basic_result<R, S, T>&, const outcome_v2::basic_outcome<R, S, P, N>&) [with T = int; U = std::error_code; V = outcome_v2::policy::error_code_throw_as_system_error<int, std::error_code, void>; R = int; S = std::error_code; P = std::__exception_ptr::exception_ptr; N = outcome_v2::policy::error_code_throw_as_system_error<int, std::error_code, std::__exception_ptr::exception_ptr>]'
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/basic_outcome.hpp:1093:1:   required from 'constexpr bool outcome_v2::operator==(const outcome_v2::basic_result<R, S, T>&, const outcome_v2::basic_outcome<R, S, P, N>&) [with T = int; U = std::error_code; V = outcome_v2::policy::error_code_throw_as_system_error<int, std::error_code, void>; R = int; S = std::error_code; P = std::__exception_ptr::exception_ptr; N = outcome_v2::policy::error_code_throw_as_system_error<int, std::error_code, std::__exception_ptr::exception_ptr>]'
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/comparison.cpp:87:5:   required from here
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/basic_outcome.hpp:1093:72: fatal error: template instantiation depth exceeds maximum of 900 (use '-ftemplate-depth=' to increase the maximum)
 1093 | OUTCOME_TREQUIRES(OUTCOME_TEXPR(std::declval<basic_outcome<R, S, P, N>>() == std::declval<basic_result<T, U, V>>()))
      |                                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/basic_outcome.hpp:1093:1: note: in expansion of macro 'OUTCOME_TREQUIRES'
 1093 | OUTCOME_TREQUIRES(OUTCOME_TEXPR(std::declval<basic_outcome<R, S, P, N>>() == std::declval<basic_result<T, U, V>>()))
      | ^~~~~~~~~~~~~~~~~
/home/conda/staged-recipes/build_artifacts/outcome-cpp_1657104035881/work/test/tests/../../include/outcome/basic_outcome.hpp:1093:19: note: in expansion of macro 'OUTCOME_TEXPR'
 1093 | OUTCOME_TREQUIRES(OUTCOME_TEXPR(std::declval<basic_outcome<R, S, P, N>>() == std::declval<basic_result<T, U, V>>()))
      |                   ^~~~~~~~~~~~~
compilation terminated.

System info

     active environment : base
    active env location : /opt/conda
            shell level : 1
       user config file : /home/conda/.condarc
 populated config files : /opt/conda/.condarc
                          /home/conda/.condarc
          conda version : 4.13.0
    conda-build version : 3.21.9
         python version : 3.9.13.final.0
       virtual packages : __linux=5.13.0=0
                          __glibc=2.17=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /opt/conda  (writable)
      conda av data dir : /opt/conda/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : /home/conda/staged-recipes/build_artifacts/pkg_cache
                          /opt/conda/pkgs
       envs directories : /opt/conda/envs
                          /home/conda/.conda/envs
               platform : linux-64
             user-agent : conda/4.13.0 requests/2.28.1 CPython/3.9.13 Linux/5.13.0-1031-azure centos/7.9.2009 glibc/2.17
                UID:GID : 1001:1001
             netrc file : None
           offline mode : False

CMake configuration

-- Found Git: /opt/conda/bin/git (found version "2.37.0") 
-- The C compiler identification is GNU 10.3.0
-- The CXX compiler identification is GNU 10.3.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: $BUILD_PREFIX/bin/x86_64-conda-linux-gnu-cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: $BUILD_PREFIX/bin/x86_64-conda-linux-gnu-c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Failed
-- Looking for pthread_create in pthreads
-- Looking for pthread_create in pthreads - not found
-- Looking for pthread_create in pthread
-- Looking for pthread_create in pthread - found
-- Found Threads: TRUE  
-- Found PythonInterp: $BUILD_PREFIX/bin/python (found version "3.8.13") 
-- Using cached scan of project outcome headers ...
-- Using cached scan of project outcome tests ...
-- Performing Test COMPILER_HAS_UBSAN
-- Performing Test COMPILER_HAS_UBSAN - Success
-- Performing Test COMPILER_HAS_ASAN
-- Performing Test COMPILER_HAS_ASAN - Success
-- Performing Test COMPILER_HAS_MSAN
-- Performing Test COMPILER_HAS_MSAN - Failed
-- Performing Test COMPILER_HAS_TSAN
-- Performing Test COMPILER_HAS_TSAN - Success
-- Performing Test COMPILER_HAS_SAFESTACK
-- Performing Test COMPILER_HAS_SAFESTACK - Failed
-- Performing Test COMPILER_HAS_STACK_PROTECTOR
-- Performing Test COMPILER_HAS_STACK_PROTECTOR - Success
-- Performing Test CXX_HAS_CONCEPTS_BY_DEFAULT
-- Performing Test CXX_HAS_CONCEPTS_BY_DEFAULT - Failed
-- Performing Test CXX_HAS_CONCEPTS_CLANG_GCC
-- Performing Test CXX_HAS_CONCEPTS_CLANG_GCC - Success
-- Performing Test CXX_HAS_COROUTINES_BY_DEFAULT
-- Performing Test CXX_HAS_COROUTINES_BY_DEFAULT - Failed
-- Performing Test CXX_HAS_COROUTINES_WITH_FLAG
-- Performing Test CXX_HAS_COROUTINES_WITH_FLAG - Success
-- Performing Test CXX_HAS_COROUTINES_WITH_FLAG_TS
-- Performing Test CXX_HAS_COROUTINES_WITH_FLAG_TS - Failed
-- NOTE: This compiler claims to support C++ 20, enabling for unit test suite
-- Configuring done
-- Generating done
-- Build files have been written to: $SRC_DIR/_build

Trying to build outcome on Windows with MSVC results in error C2259 cannot instantiate abstract class.

Build error

FAILED: CMakeFiles/outcome_hl--experimental-core-result-status.dir/test/tests/experimental-core-result-status.cpp.obj 
C:\PROGRA~2\MICROS~1\2019\ENTERP~1\VC\Tools\MSVC\1416~1.270\bin\HostX64\x64\cl.exe  /nologo /TP -D_CRT_NONSTDC_NO_WARNINGS -I%SRC_DIR%\include -I%SRC_DIR%\quickcpplib\_install\include /DWIN32 /D_WINDOWS /W3    /O2 /Ob2 /DNDEBUG /EHsc /MD /W4 /permissive- -std:c++latest /showIncludes /FoCMakeFiles\outcome_hl--experimental-core-result-status.dir\test\tests\experimental-core-result-status.cpp.obj /FdCMakeFiles\outcome_hl--experimental-core-result-status.dir\ /FS -c %SRC_DIR%\test\tests\experimental-core-result-status.cpp
cl : Command line warning D9025 : overriding '/W3' with '/W4'
%SRC_DIR%\test\tests\experimental-core-result-status.cpp(109): error C2259: '_payload_domain': cannot instantiate abstract class
%SRC_DIR%\test\tests\experimental-core-result-status.cpp(109): note: due to following members:
%SRC_DIR%\test\tests\experimental-core-result-status.cpp(109): note: 'system_error2::status_code_domain::payload_info_t system_error2::status_code_domain::payload_info(void) noexcept const': is abstract
c:\bld\outcome-cpp_1657102439357\work\include\outcome\experimental\status-code\include\status_code_domain.hpp(408): note: see declaration of 'system_error2::status_code_domain::payload_info'
[22/250] Building CXX object CMakeFiles\outcome_hl--experimental-p0709a.dir\test\tests\experimental-p0709a.cpp.obj
FAILED: CMakeFiles/outcome_hl--experimental-p0709a.dir/test/tests/experimental-p0709a.cpp.obj 
C:\PROGRA~2\MICROS~1\2019\ENTERP~1\VC\Tools\MSVC\1416~1.270\bin\HostX64\x64\cl.exe  /nologo /TP -D_CRT_NONSTDC_NO_WARNINGS -I%SRC_DIR%\include -I%SRC_DIR%\quickcpplib\_install\include /DWIN32 /D_WINDOWS /W3    /O2 /Ob2 /DNDEBUG /EHsc /MD /W4 /permissive- -std:c++latest /showIncludes /FoCMakeFiles\outcome_hl--experimental-p0709a.dir\test\tests\experimental-p0709a.cpp.obj /FdCMakeFiles\outcome_hl--experimental-p0709a.dir\ /FS -c %SRC_DIR%\test\tests\experimental-p0709a.cpp
cl : Command line warning D9025 : overriding '/W3' with '/W4'
%SRC_DIR%\test\tests\experimental-p0709a.cpp(90): error C2259: '_arithmetic_errc_domain': cannot instantiate abstract class
%SRC_DIR%\test\tests\experimental-p0709a.cpp(90): note: due to following members:
%SRC_DIR%\test\tests\experimental-p0709a.cpp(90): note: 'system_error2::status_code_domain::payload_info_t system_error2::status_code_domain::payload_info(void) noexcept const': is abstract
c:\bld\outcome-cpp_1657102439357\work\include\outcome\experimental\status-code\include\status_code_domain.hpp(408): note: see declaration of 'system_error2::status_code_domain::payload_info'

System info

     active environment : base
    active env location : C:\Miniforge
            shell level : 1
       user config file : C:\Users\VssAdministrator\.condarc
 populated config files : C:\Miniforge\.condarc
                          C:\Users\VssAdministrator\.condarc
          conda version : 4.12.0
    conda-build version : 3.21.9
         python version : 3.9.13.final.0
       virtual packages : __win=0=0
                          __archspec=1=x86_64
       base environment : C:\Miniforge  (writable)
      conda av data dir : C:\Miniforge\etc\conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : C:\Miniforge\pkgs
                          C:\Users\VssAdministrator\.conda\pkgs
                          C:\Users\VssAdministrator\AppData\Local\conda\conda\pkgs
       envs directories : C:\Miniforge\envs
                          C:\Users\VssAdministrator\.conda\envs
                          C:\Users\VssAdministrator\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/4.12.0 requests/2.27.1 CPython/3.9.13 Windows/10 Windows/10.0.17763
          administrator : True
             netrc file : None
           offline mode : False

CMake configure step

-- The C compiler identification is MSVC 19.16.27048.0
-- The CXX compiler identification is MSVC 19.16.27048.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/cl.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Enterprise/VC/Tools/MSVC/14.16.27023/bin/HostX64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - not found
-- Found Threads: TRUE  
-- Found PythonInterp: C:/bld/outcome-cpp_1657102439357/_build_env/python.exe (found version "3.7.12") 
-- Using cached scan of project outcome headers ...
-- Using cached scan of project outcome tests ...
-- Performing Test CXX_HAS_CONCEPTS_BY_DEFAULT
-- Performing Test CXX_HAS_CONCEPTS_BY_DEFAULT - Failed
-- Performing Test CXX_HAS_COROUTINES_BY_DEFAULT
-- Performing Test CXX_HAS_COROUTINES_BY_DEFAULT - Failed
-- Performing Test CXX_HAS_COROUTINES_MSVC_STD20
-- Performing Test CXX_HAS_COROUTINES_MSVC_STD20 - Failed
-- Performing Test CXX_HAS_COROUTINES_MSVC_AWAIT
-- Performing Test CXX_HAS_COROUTINES_MSVC_AWAIT - Success
-- NOTE: This compiler claims to support C++ 20, enabling for unit test suite
-- Configuring done
-- Generating done
-- Build files have been written to: C:/bld/outcome-cpp_1657102439357/work/_build

Trying to configure outcome with cmake -B _build -G Ninja -DCMAKE_BUILD_TYPE=Release fails with

CMake Warning at _build/quickcpplib/repo/cmakelib/QuickCppLibUtils.cmake:84 (message):
  WARNING: .clang-tidy file found for project outcome, yet clang-tidy not on
  PATH so disabling lint pass
Call Stack (most recent call first):
  _build/quickcpplib/repo/cmakelib/QuickCppLibSetupProject.cmake:205 (indented_message)
  CMakeLists.txt:51 (include)


-- Missing dependency quickcpplib is NOT installed in cmake packages!
-- Missing dependency quickcpplib is NOT found at $SRC_DIR/_build/quickcpplib!
-- Superbuilding missing dependency quickcpplib with config Debug, this may take a while ...
CMake Error at _build/quickcpplib/repo/cmakelib/QuickCppLibUtils.cmake:95 (message):
  FATAL: Configure download, build and install of quickcpplib with
  -DCMAKE_BUILD_TYPE=Debug -G "Ninja" -DPROJECT_IS_DEPENDENCY=TRUE
  "-DQUICKCPPLIB_ROOT_BINARY_DIR=/home/conda/staged-recipes/build_artifacts/outcome-cpp_1656676380527/work/_build"
  failed with error '1'

  

  stdout was: -- Configuring incomplete, errors occurred!

  See also
  "/home/conda/staged-recipes/build_artifacts/outcome-cpp_1656676380527/work/_build/quickcpplib/CMakeFiles/CMakeOutput.log".


  

  

  stderr was: CMake Error: CMake was unable to find a build program
  corresponding to "Unix Makefiles".  CMAKE_MAKE_PROGRAM is not set.  You
  probably need to select a different build tool.

Call Stack (most recent call first):
  _build/quickcpplib/repo/cmakelib/QuickCppLibUtils.cmake:277 (checked_execute_process)
  _build/quickcpplib/repo/cmakelib/QuickCppLibUtils.cmake:371 (download_build_install)
  CMakeLists.txt:84 (find_quickcpplib_library)

It seems like the generator, in this case ninja is not communicated correctly. Using ninja would be useful for usage on Windows.

Repro and detailed description here:

https://godbolt.org/z/YG6e8q3Y5

Excerpt:

using Result =
    outcome::result<std::tuple<int, std::string>, InHouseErrorz *, MyNVP>;

auto foo() {
    Result r{1, "a"};
    // r = nullptr; //< UNCOMMENT to eliminate warning
    r = {2, "b"};
    return r.assume_value();
}

Very likely that this is a GCC issue (in fact, can't be reproduced in trunk). Yet, it is a curious phenomenon and causing production hassle with our boost upgrade. I am wondering if this is an expected change with later Outcome versions, or worse and crucially if the usage in the reproduction code is somewhat making incorrect assumptions.

Or, if there is confirmation this is just a silly GCC bug, it'd be a good enough resolution.

thanks