Mere moments ago, quoth I:
But without that, it's still possible with:
if (r.has_error()) { (void) r.value(); /* will throw */ }
(Slight downside of this is that the compiler has to inline and walk into value() before realising that it always throws, so it might emit warnings unless you add some extra boilerplate.)
Though to be fair, this is a bit contrived in isolation; it's likely that code that makes use of that behaviour would more naturally be written as: auto value = do_something().value(); // that threw if empty, error, or exception, // so now you can safely play with value. The main point being that I'm not sure how useful it would be to have .exception() contain a synthetic exception in the non-thrown cases. (But then, normally you don't want to catch and transport exceptions at all, which is why result<T> exists. outcome<T> and exception transport only becomes useful when you're about to exit from an exception-enabled island into a sea of noexcept, to use Niall's phrasing.)