One of the questions that is inevitably asked when a proposal to switch to using something like outcome is that of exceptions. Why outcome over exceptions etc which you briefly touch on in your ACUU talk. With that in mind, when attempting to sell this library having the motivating example on the boost.outcome docs using exceptions really makes starting the discussion harder. I understand one can never escape exceptions, but it shouldn't be used as the first example a new user sees. I would like to see this example updated to show how to handle errors with out the need for exception handling around accessing *value*. Personally, I see something similar to https://ned14.github.io/boost.outcome/md_doc_md_03-tutorial_b.html#expected_... as a much better example to help sell outcome and therefore better suited as the motivating example for the front page of the docs.
The motivating example on the landing page is very tricky to get right. It can't be too long, else people give up instantly. It can't use too much library specific stuff, else it overwhelms. It has to assume a very wide range of viewer knowledge and capability. Yet it must still communicate the library in an instant, including that it works well with mixed C++ exceptions enabled and disabled codebases. The current motivating example was written by Andrzej because my previous one wasn't representative enough. I am not a good person to write these landing page code examples, I never look at them when looking at a library and they play zero part in my evaluation of a library when considering to use it. So I have no idea what other people, who do rely on these heavily, look for. Vicente suggested a different example by Andrzej instead. I will re-ponder that one. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/