1. No checking. This is performance optimised and leads to UB. (In Ye Olde Outcome, it would have returned a garbage bit pattern that could cause all sorts of weird logic, though probably not any far-reaching harm due to the way error_code itself works. In Outcome v2 it's most likely going to just return a default-initialised one, which is entirely harmless.)
Not to nitpick, but as https://ned14.github.io/outcome/tutorial/default-actions/happens1/#fn:1 describes, calling .error() when there is no error there results in *hard* UB. As in, the compiler doesn't generate code to handle the situation where there is no error, no branches, no stack handling, nothing. The consequence of that *might* be to proceed as if there is no error, but sometimes it is not. The Tutorial gives an example of where it segfaults. You can't really say, depends on what the optimiser generates for some given situation. Now, in terms of storage, yes we do always place default initialised E in there. That's for the C compatibility. But we don't place a default initialised T there, that can be random bits, so .value() where there is no value can yield the same random input as you mentioned Outcome v1 had. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/