On 24/05/2017 03:26, Peter Dimov wrote:
Would you still say the above after considering my idea for a family of "rigorous" outcomes?
I must have missed that, sorry. I looked a few messages back in this thread but didn't find it.
Back at the beginning when designing Outcome, one of my design ideas was a variety which called std::terminate on destruction if an error had never been retrieved. So, the idea behind this family of Outcomes was that they were "single shot", .error() and .value() could be called exactly once after which the outcome became empty. On destruction, if an error had never been retrieved, it was fatal exit time.
I never found a use for that particular variety in my own code, but I find the semantics very attractive. They impose rigour. I just wish I could make the statically obvious failure to collect state a compile time instead of runtime error. Personally I'm not a fan of code that causes std::terminate to get called for any reason, but that comes from my biases of mostly working on code where it's ok to misbehave briefly (as it's usually self correcting, especially if you can throw an exception to abandon a
Fairly certain he was referring to the suggestion earlier in the same message, ie: On 24/05/2017 03:19, Niall Douglas wrote: particular task while letting other tasks continue) but it's not ok to stop doing everything. This is partly why I've hesitated to say anything about Outcome thus far; I'm not sure I'm part of its target audience. (I work on low-latency code as with games but either with exceptions and /EHa enabled for the soft code and not even using C++ for the hard code.)